Business Analyst Community & Resources | Modern Analyst

Business Analysis in the Age of AI

Pulkit Singhal — Fri, 01 May 2026 19:24:00 GMT

Business analysis work has become faster and more efficient over the past few years. Requirements are documented more quickly, discussions are summarized sooner, and solution options are produced earlier in the delivery cycle than ever before. Yet many Agile and product teams are discovering an unexpected truth: as delivery accelerates, the importance of human judgment increases rather than diminishes.

The central question facing business analysts today is no longer whether tools and automation belong in analysis work, but where judgment must take precedence. That distinction matters because the most serious failures in delivery rarely come from obvious mistakes. They emerge from reasonable decisions that appear correct at the time and gradually move teams off course.

Where Acceleration Helps and Where It Falls Short

Modern analysis practices are excellent at speeding up work that is inherently mechanical:

Converting discussions into draft requirements
Identifying patterns across large volumes of data
Refining user story language
Summarizing customer or stakeholder feedback

When used well, this removes low‑value effort from the analyst’s workload. When relied upon uncritically, it creates the illusion of progress.

The challenge is not poor quality output. The real risk lies in outputs that are clear, structured, and confident enough to pass surface review, while subtly reinforcing incorrect assumptions. This is where judgment becomes decisive.

Judgment Gap #1: Determining Whether a Requirement Is Worth Building

Clear and complete requirements do not guarantee meaningful outcomes.

In day‑to‑day delivery, analysts encounter familiar patterns:

A requirement addresses a visible symptom rather than the underlying problem
Stakeholders agree on wording but diverge on expected results
A feature meets acceptance criteria yet produces no behavioral change

Experienced analysts pause to ask questions that artifacts alone cannot answer:

What decision or behavior is supposed to change as a result of this work?
If this is delivered perfectly and nothing improves, what are we missing?

Strong analysis is not just about expressing requirements well, but about challenging their intent.

Judgment Gap #2: Interpreting Context That Never Appears in Documentation

Business environments contain layers of context that rarely make it into requirements or datasets:

Organizational dynamics and power structures
Regulatory concerns driving risk‑averse behavior
Legacy failures that shape stakeholder trust
Competing incentives across teams

Analysts recognize these signals not because they are documented, but because they have seen the downstream effects:

Solutions that are functionally correct but poorly adopted
Processes that are bypassed in practice
Reports and dashboards that exist but are ignored

Judgment here is not guesswork. It is pattern recognition developed through exposure to real consequences.

Judgment Gap #3: Recognizing When Clarity Creates False Confidence

Early clarity is often welcomed as momentum. Detailed backlogs, well‑defined flows, and polished models can make teams feel aligned and confident.

Seasoned analysts remain cautious.

They ask whether clarity is reducing uncertainty—or simply hiding it:

Are assumptions being locked in too early?
What would invalidate this design once it is tested?
Are open questions being resolved, or quietly deferred?

Sometimes the most responsible decision is to leave things deliberately unresolved, even when tools and processes encourage premature finalization.

What This Means for Business Analysts

As delivery mechanics become faster, the value of business analysis shifts away from producing artifacts and toward exercising judgment:

Framing the right problems
Interpreting conflicting signals
Evaluating consequences under uncertainty
Challenging assumptions before they harden

These capabilities are not procedural skills. They are developed through experience, reflection, and exposure to real outcomes especially failure.

Closing Thoughts

Modern tools and practices have made business analysis more efficient, but efficiency does not replace responsibility. The most effective analysts are not those who produce the most artifacts in the shortest time. They are the ones who know when clarity is helpful, when it is premature, and when the best contribution is to pause and ask a different question altogether.

That work remains deeply human and central to successful delivery.

Reinventing the Annual Member Survey: A Business Analyst’s Role in Delivering Actionable Insights

Pulkit Singhal — Sun, 25 Jan 2026 02:38:00 GMT

In a competitive and rapidly evolving financial landscape, understanding member needs is vital to maintaining strong relationships and delivering meaningful value. Yet for many institutions, especially those with legacy processes, collecting structured member feedback can be surprisingly underdeveloped. This was the case at the Federal Home Loan Bank of Chicago (FHLBank Chicago), where — despite its extensive engagement with member institutions — the Bank had never before conducted a structured, enterprise-wide Annual Member Survey.

Recognizing the need for a formalized feedback mechanism, the Bank launched an initiative to design and implement its first-ever Annual Member Survey, leveraging Salesforce as the foundational platform. As the Lead Business Analyst, I was responsible for envisioning, architecting, and orchestrating this new capability from the ground up.

This initiative ultimately became a defining example of how strategic business analysis can create net-new organizational capability, not just improve existing processes.

The Challenge: Creating a Strategic Feedback Framework from Scratch

Unlike most process-automation projects, this effort did not begin with an existing workflow to analyze or improve. Instead, the Bank faced a unique challenge:

No prior survey process existed
No historical data or response structures were available to benchmark against
No distribution, tracking, or reporting mechanisms had been established
No governance model existed for how results should be consumed
Stakeholders possessed varying assumptions about what the new survey should accomplish

This meant the project required not only systems expertise but also conceptual design, stakeholder alignment, and strategic framing.

My Role as Lead BA: Designing a New Enterprise Capability

The absence of an existing process meant that Business Analysis would shape the entire direction of the initiative. My responsibilities included defining the business problem, creating the process architecture, establishing data structures, and ensuring Salesforce could support a sustainable and scalable survey model.

1. Establishing the Vision and Framing the Purpose

Through interviews and collaborative workshops with Member Strategy, Sales, Analytics, and Leadership teams, I led discussions to answer foundational questions:

What insights should the Bank gather annually?
How should “member satisfaction” be defined in measurable terms?
What KPIs would create genuine value for leadership?
How should results be tied back to member institutions in Salesforce?

This work produced the Bank’s first Survey Vision and Strategy Framework, guiding all subsequent design decisions.

2. Building the End‑to‑End Survey Workflow in Salesforce

Because no prior workflow existed, I architected a brand‑new process designed around clarity, automation, and scalability:

Designed the survey creation and distribution model
Built logic for survey-to-member linking
Defined the response-collection data structure
Modeled the end‑to‑end visibility lifecycle, including assignment, participation, reminders, and results
Ensured dashboards would give leadership real-time insights

The process not only captured survey responses but also embedded insights directly into the Bank’s member management ecosystem.

3. Translating Ambiguity Into Clear, Actionable Requirements

Given the lack of precedent, requirements had to be derived through deep analysis rather than comparison. I authored:

Detailed user stories
Acceptance criteria
Process maps
Data models
Reporting definitions

This documentation became the foundational blueprint for developers, testers, and end-users — eliminating ambiguity and creating shared understanding.

4. Leading UAT and Validating a New Capability

Because the Bank had never conducted a survey like this, UAT required additional rigor:

I designed test scripts covering every stage of the survey lifecycle
Trained business stakeholders on how to test a process that was entirely new
Triaged defects and clarified user expectations
Ensured the system was intuitive and future-proofed

Through this, the Bank gained confidence not just in the technology, but in the process itself.

5. Supporting Rollout, Adoption, and Governance

Beyond system delivery, I worked closely with:

Member Strategy teams to formalize interpretation of results
Analytics teams to align on scoring and reporting methodologies
Change management teams to ensure smooth onboarding
Salesforce admins to embed long‑term maintainability

This ensured the survey became an annual, repeatable, institution-wide capability—not a one‑off project.

Conclusion: This project shows that Business Analysts are not just process improvers—they are capability creators.By clarifying needs, defining strategy, architecting processes, aligning teams, and ensuring quality, the BA function enabled FHLBank Chicago to establish a powerful new insight mechanism that will shape strategy for years to come.

The Annual Member Survey is now more than a project deliverable.
It is a permanent intelligence asset for the Bank — built on a foundation of Business Analysis leadership.

Driving Social Value Through Business Analysis

Demilade — Thu, 18 Sep 2025 06:40:00 GMT

When people discuss business analysis, they typically think of requirements, processes, or systems. But one of the most rewarding projects I’ve worked on was very different: improving how my company reported its social value.

Social value is about the positive impact an organisation makes beyond profit, things like sustainability and community engagement. Reporting on this sounds simple, but in practice, it’s messy. Social value data resides in various locations, teams often disagree on what constitutes value, and the process can become a time-consuming exercise in copy-pasting and reconciliation. That was the situation I walked into.

My role was to bring order: to make social value reporting clear, consistent, and aligned with the TOMS (Themes, Outcomes and Measures) framework, which is the UK standard for measuring social value.

The Challenge

Now, this project was an interesting one because it had been running without a business analyst for over 2 years, based on the initial assumption that it was a simple reporting project and all social value data was readily available. The first thing I noticed was how fragmented everything was. One team had a spreadsheet for apprentice data. Another team tracked veteran data in emails. The sustainability team had their own systems entirely. When month-end and year-end came around, pulling it all together felt more like detective work than reporting.

Even worse, there was no agreement on what each TOMS metric actually meant. For example, one TOMS metric we were to report on was the organisation’s spend within local VCSEs, and I remember validating that metric with the data owner, and they threw me a curveball by asking me what our definition of “local” was.

So this wasn’t just an internal challenge. Clients and regulators wanted clear evidence of impact, and the company risked underselling and misrepresenting the great work it was already doing. So we were faced with the problem of automating the reporting and secondly auditing the data to prove data integrity to regulators and auditors.

My Role as a Business Analyst

I started by listening. I met with corporate social responsibility leads, finance, supply management, and operations to understand what they tracked and why. Those conversations made one thing clear: everyone cared about social value, but they all saw it from different perspectives without appreciating the bigger picture, like how the data they were responsible for contributed to the bid win rate and the company’s performance against the TOMS framework. their own lens.

To move forward, I facilitated workshops with the various data owners where we mapped out the as-is reporting processes, highlighting data sources and formats. Seeing the flow together, how social value data was captured, how it was stored, and where it got lost, helped people realise why reports were inconsistent. I identified bottlenecks and gaps which the business had to address to allow for reporting automation.

From there, I re-baselined requirements to ensure they reflected both the company’s current strategic goals and the practical realities of reporting. My role was about translation, bringing clarity to chaos.

The Solution

The organisation had over 150 TOMS metrics that they wanted to report on. So you can imagine I had to negotiate with the project sponsor and relevant stakeholders to prioritise 20 TOMS initially for the MVP build. Doing this helped the project team align and narrow on scope.

We agreed on a standardised reporting template of TOMS metrics: volunteering hours, local sourcing, sustainability initiatives, training programs, and a few others. Each department knew what they were responsible for, and how it would be measured and what was required in order to verify the data.

Because it’s one thing to say we are employing X amount of veterans, but how do we actually prove that what we say is true?

On the technical side, we moved away from chasing spreadsheets and emails. Data collection was integrated into existing systems, where we pulled relevant data into the standardised reporting template. A central reporting platform was built so teams could see their contributions in near real time instead of waiting until the end of the month. To protect sensitive data, access was controlled using MFA and role-based access.

This wasn’t just about efficiency. For the first time, social value reporting felt like part of the business rhythm rather than an afterthought.

The Impact

The difference was clear almost immediately. A reporting cycle that used to take nearly three weeks could now be done in under a week. Reporting errors dropped because the numbers were coming from standardised inputs instead of being retyped multiple times.

The bigger win was credibility. Clients could see clearly how the company was delivering on its commitments as we were able to show our company’s social value performance against a national benchmark using the TOMS framework. Internally, leadership started using the data to guide decisions, like investing more in initiatives that had the biggest measurable impact, such as a reduction in plastic use and carbon emissions, which were part of the organisation’s net zero initiative.

What started as a compliance requirement turned into something more valuable: a tool for telling the company’s story and strengthening its reputation amongst competitors.

I’m also going to toot my horn here because this was a clear example of why Business Analysts are needed on projects. For over two years, the project had run without direction, but within just two weeks, I was able to bridge the gap between teams, bring clarity, and give the project the focus it needed. This not only unblocked delivery and achieved the required impact, but also influenced lasting change. As a direct result of lessons learned, a new and improved demand intake process was introduced to properly scope projects before they were taken on, strengthening how reporting was managed across the business going forward.

Insights for Other Business Analysts

Looking back, a couple of takeaways that stand out that might help other BAs facing similar issues:

Get alignment early. If people don’t agree on what “value” means, no amount of process or technology will fix the problem.
Make it visible. People typically tend to understand things better when it’s presented to them visually. I used red to highlight manual interfaces between systems. This trick helped me highlight the reality of the situation to stakeholders
Build for change. Social value expectations will keep evolving—your framework should be flexible enough to grow. Remember, we had an initial 20 TOMS. What happens if the business wants to introduce new social value metrics? I ensured that the solution being developed was easily scalable to the remaining existing TOMS and new TOMS by capturing it as a non-functional requirement and performing requirements traceability to ensure it was considered, handled and delivered by the developers
Consider more than just compliance. Reports can be effective tools for storytelling and engagement, and they are not only for auditors. In my case, the company could now highlight their dedication to social value in their bids, setting them apart from competitors.
Security first mindset. In all you do, always employ a security-first mindset. Think about user/role access early on. I know it may seem daunting, but it saves you a lot of time and effort further down the line.
Verify, verify, verify: when joining a project midway, try to understand the business needs first. This would guide you along. Also, verify whatever information you are provided in the already existing documentation and ensure you get sign-off on every artefact you create. In my case, there were some inconsistencies with identified data sources, and the previous requirements were too high-level, leaving room for ambiguity.

The Bigger Picture

This project reminded me that business analysis isn’t just about requirements, systems or workflows. At its best, it’s about helping organisations define what matters, measure it properly, and act on it.

For me, this showed that we as BAs can play a role in shaping not just business outcomes but also social impact. And in a world where clients and communities care deeply about both, that’s work worth doing.

Author: Demi Adeyemo

Demi is a startup founder and business analyst specialising in technology, data, and digital innovation. He has delivered solutions across finance, social value, HR, education, food services, and facilities management, helping organisations solve complex business problems and achieve measurable impact. With an MSc in Data Science & Artificial Intelligence, Demi applies his technical expertise to drive business transformation and AI adoption.

The Business Analyst's Superpower: Bridging the Gap Between Business and IT

Jayaram.K — Thu, 08 May 2025 09:58:00 GMT

In today's fast-paced digital world, successful projects aren't just built on great code—they're built on clarity. And that clarity often comes from one key player: the Business Analyst.

At the heart of every great product or system is a need—a business goal, a customer pain point, or a regulatory requirement. But business stakeholders often don’t speak in system specs, and developers don’t always grasp the business context. This is where the Business Analyst (BA) steps in, acting as the bridge between business and technology.

I've seen firsthand how this gap can create chaos. In one project, the absence of a BA led to a product that was technically sound—but completely misaligned with user expectations. Features were overbuilt, timelines slipped, and rework was costly. When a BA joined the next sprint, everything changed. Requirements became clear, priorities were realigned, and delivery became smoother.

So how exactly do BAs bridge this gap?

We listen—actively and empathetically. We facilitate workshops, ask “why” more than once, and challenge assumptions. We translate business needs into clear, actionable artifacts—whether it’s user stories, process models, or use cases. And most importantly, we make sure every stakeholder feels heard.

A BA’s toolkit is powerful. Tools like JIRA, Confluence, Lucidchart, or Figma help us document, visualize, and track requirements. But it’s not just about tools—it’s about asking the right questions and fostering collaboration.

In my experience, the most successful BAs aren’t just requirement gatherers. They’re strategic partners. They understand the domain (whether it’s insurance, capital markets, or telecom), anticipate risks, and help shape solutions that truly add value.

Ultimately, a good BA doesn’t just connect departments—they align visions. That’s our superpower.

If you’re a BA reading this, I’d love to hear: How have you bridged the gap on your projects?

How to Prepare for the CCNA Certification Exam

sg0883564 — Fri, 20 Sep 2024 08:40:00 GMT

The Cisco Certified Network Associate (CCNA) certification is a pivotal credential for networking professionals, validating your skills in networking fundamentals, security, automation, and programmability. Preparing for the CCNA exam can be challenging, but with the right strategy, resources, and mindset, you can successfully achieve this certification. In this article, we’ll explore a comprehensive approach to preparing for the CCNA certification exam.

Understanding the CCNA Certification

Before diving into preparation strategies, it's essential to understand what the CCNA certification in Miami FL entails. The exam tests knowledge in various domains, including:

Network Fundamentals: Understanding network concepts, models, and architecture.
IP Connectivity: Knowledge of IP addressing, routing protocols, and basic troubleshooting.
IP Services: Familiarity with services like DHCP, NAT, and DNS.
Security Fundamentals: Basics of network security principles and threats.
Automation and Programmability: An introduction to network automation and APIs.

The CCNA exam is a stepping stone for many IT professionals, opening doors to advanced certifications and specialized areas within networking.

Setting Up Your Study Plan

A well-structured study plan is crucial for effective preparation. Here’s a step-by-step guide to create your plan:

1. Assess Your Current Knowledge

Before you begin studying, evaluate your existing knowledge of networking concepts. Identify areas where you feel confident and those that require more focus. This assessment will help tailor your study plan.

2. Choose a Study Methodology

There are various ways to prepare for the CCNA exam, including:

Self-Study: Utilizing books, online courses, and resources.
Formal Classes: Enrolling in a local or online training program.
Study Groups: Collaborating with peers to enhance learning through discussion and shared resources.

Choose the methodology that aligns with your learning style and schedule.

3. Create a Study Schedule

Consistency is key. Develop a study schedule that breaks down topics into manageable sections. For instance, you might allocate specific weeks for each exam domain, ensuring you cover all material before your exam date. Aim for daily study sessions, setting aside at least 1-2 hours to focus on networking concepts.

Resources for CCNA Preparation

The quality of your study materials can significantly impact your preparation. Here are some recommended resources:

1. Official Cisco Resources

Cisco offers a wealth of resources to aid your preparation:

Cisco Learning Network: An online platform with study materials, forums, and additional resources.
CCNA Exam Blueprint: Familiarize yourself with the exam objectives and structure outlined in the official blueprint.

2. Books and Study Guides

A few highly recommended books for CCNA preparation include:

"CCNA 200-301 Official Cert Guide" by Wendell Odom: A comprehensive guide covering all exam objectives.
"31 Days Before Your CCNA Exam" by Allan Johnson: A focused approach for last-minute preparation.

3. Online Courses and Videos

Many online platforms offer CCNA courses, such as:

Udemy: Various instructors provide detailed courses that cover all exam topics.
Pluralsight: Offers in-depth courses and practice labs for hands-on experience.

4. Practice Tests

Practice tests are essential for gauging your readiness. Use platforms like:

Boson: Known for high-quality practice exams that simulate the actual test experience.
Cisco’s Official Practice Test: This is an excellent way to familiarize yourself with exam format and types of questions.

Hands-On Experience

Networking is a practical field, and hands-on experience is crucial for understanding concepts deeply. Here are some ways to gain practical knowledge:

1. Home Lab Setup

Building a home lab can greatly enhance your understanding. You can use physical routers and switches or simulators like:

Cisco Packet Tracer: A free tool that allows you to simulate network configurations.
GNS3: A powerful network emulator for more complex setups.

2. Lab Exercises

Incorporate lab exercises into your study plan. Focus on configuring routers and switches, setting up VLANs, implementing security measures, and troubleshooting common network issues.

3. Networking Projects

Engage in small networking projects or scenarios that mimic real-world applications. This could involve setting up a home network, configuring firewall settings, or creating a virtual private network (VPN).

Join Study Groups and Forums

Engaging with peers can enhance your learning experience. Consider joining:

Online Forums: Websites like Reddit’s r/ccna or Cisco’s Learning Network provide platforms for discussion, question-asking, and resource sharing.
Local Study Groups: Collaborate with fellow aspiring CCNA candidates in your area to discuss challenging topics and share insights.

Exam Day Preparation

As your exam date approaches, it's essential to have a plan for exam day:

1. Review Exam Logistics

Know the exam location, format, and what to expect. Ensure you have all required materials ready, including identification and any necessary confirmations.

2. Final Review

In the last week leading up to the exam, focus on reviewing key concepts rather than trying to learn new material. Utilize flashcards, review notes, and take a few practice exams to build confidence.

3. Stay Calm and Focused

On exam day, ensure you’re well-rested and eat a good breakfast. Arrive at the testing center early to avoid any last-minute stress. During the exam, read each question carefully and manage your time effectively.

Conclusion

Preparing for the CCNA certification exam requires dedication, strategic planning, and hands-on experience. By assessing your current knowledge, utilizing quality resources, engaging with peers, and gaining practical experience, you’ll be well-equipped to tackle the CCNA exam confidently. Remember, the journey to certification is as valuable as the destination itself, so embrace the learning process and enjoy your growth in the networking field. Good luck!

The CEO/CIO's Guide to Architecting AI: Vision to Value in Minutes

Agora Insights International — Fri, 12 Jul 2024 06:19:00 GMT

The CEO/CIO's Guide to Architecting AI: Vision to Value in Minutes

Introduction to Architected AI

Artificial intelligence (AI) is becoming part of our life at an unprecedented pace. As CEOs and CIOs grapple with how to leverage this powerful technology to drive strategy and enhance operations, the concept of Architected AI becomes important. In a recent webinar, industry experts Deirdre Caren and Daniel Lambert talk through the concepts of Architected AI, providing invaluable insights for business leaders looking to harness its potential.

https://youtu.be/BCLhvrfoYXE

What is Architected AI?

At its core, Architected AI is about aligning AI with business needs to accelerate the execution of strategic initiatives. It's not just about having AI for the sake of it; it's about integrating AI intelligently into your business architecture to drive tangible results.

As Daniel Lambert highlighted, AI solutions like Aidon.ai can dramatically improve the dissemination of strategic objectives across all levels of an organization. By leveraging AI to map out detailed capability-based roadmaps, enterprises can ensure that every employee understands and contributes to the overarching strategy.

The Importance of Architecture

Before diving headfirst into AI implementation, it's crucial to have a solid foundation in place. This is where business architecture comes in. As Deirdre Caren emphasized, a clear architectural framework is a prerequisite for successful AI integration.

Business architecture provides the necessary context for AI to understand the organization's capabilities, value streams, and strategic goals. Without this foundational knowledge, AI runs the risk of becoming a costly distraction rather than a strategic asset.

Navigating the Challenges of AI Implementation

While the potential of AI is immense, implementing it is not without challenges. Data quality, integration with existing systems, and the complexity of AI tools themselves can all pose significant hurdles.

To overcome these challenges, organizations need to adopt a structured approach rooted in a robust architectural foundation. This means ensuring that data is clean, relevant, and organized before feeding it into AI models. It also involves carefully selecting AI solutions that can seamlessly integrate with existing technology stacks.

The Human Element in AI

As we marvel at the capabilities of AI, it's easy to forget the critical role that humans play in its success. The concept of 'human in the loop' underscores the importance of continuous human oversight in AI-generated content.

While AI can process vast amounts of data and provide valuable insights, it still requires human judgment to ensure that its outputs are accurate, relevant, and aligned with business objectives. As Deirdre Caren aptly put it, AI is here to augment human capabilities, not replace them.

Start Small, Think Big

One of the key takeaways from the webinar was the importance of starting small with AI integration and gradually scaling up as the organization becomes more comfortable with the technology. It's not about having the perfect knowledge base or the most sophisticated AI tools from the get-go.

Instead, it's about starting with what you have, training your models, and continuously improving as you go. AI can help identify gaps in your data and refine your Business Capability Model (BCM) over time. The key is to not let the pursuit of perfection hinder your progress.

Customizing AI for Your Organization

Off-the-shelf AI solutions can certainly provide value, but to truly unlock the potential of AI, customization is key. As Daniel Lambert pointed out, tailoring AI models to your organization's unique vocabulary, context, and industry frameworks is essential for accurate and relevant outputs.

This customization process involves training AI with your organization's specific data, tweaking industry frameworks to account for organizational bias, and continuously refining the models based on user feedback. It's an iterative process that requires close collaboration between AI experts and business stakeholders.

The Future of AI in Business

As the webinar drew to a close, one thing became abundantly clear: AI is not a future prospect; it's a present reality. CEOs and CIOs who fail to embrace its potential risk falling behind in an increasingly competitive landscape.

However, embracing AI is not about blindly jumping on the bandwagon. It's about strategically integrating AI into your business architecture, starting small, and continuously refining your approach based on real-world results.

As Deirdre Caren and Daniel Lambert emphasized, the most successful AI implementations are those that are closely aligned with business objectives and are continuously monitored and optimized by human experts. It's this synergy between human intelligence and artificial intelligence that will drive the future of business.

Key Topics and Takeaways from the Webinar on Architected AI

Understanding the Role of AI in Business Architecture

AI is not just about technology; it's about aligning with business strategies.
The concept of "architecture first" is crucial—know your business before implementing AI.
AI can understand capabilities, value streams, and organizational information if trained well.

The Different Dimensions of AI

AI encompasses a broad spectrum, including machine learning, deep learning, and generative AI.
Generative AI, like ChatGPT, is particularly transformative, capable of generating strategies and capabilities.

The Limitations and Potential of AI

AI has limitations, such as token limits and a reliance on agent identity.
The potential of AI lies in creating multiple agents that work together to augment business processes

The Importance of a Knowledge Base

A robust knowledge base is essential for AI to be effective.
AI can help organize and refine disorganized data, enhancing decision-making processes.

The Human Element in AI

Human oversight is necessary to ensure AI performs tasks correctly.
The concept of "human in the loop" involves humans checking AI's work, not the other way around.

The Future of Work with AI

AI will change job roles, emphasizing the need for knowledge workers who understand the business deeply.
Architects will need to focus more on analyzing, architecting, and designing rather than documenting.

Getting Started with AI in Your Organization

Don't wait for a perfect knowledge base to start with AI—begin with what you have.
Design AI with your business context in mind to get the most out of it.

Aidon's Role in AI Architecture

Aidon.ai is an AI solution that can customize AI models for businesses.
The company is looking to work with a select group of companies to tailor AI to their architecture needs.

Conclusion

Architected AI represents a paradigm shift in how businesses approach strategy and operations. By aligning AI capabilities with business needs, organizations can accelerate the execution of strategic initiatives and gain a significant competitive advantage.

However, the path to successful AI implementation is not without its challenges. It requires a strong foundation in business architecture, a structured approach to data management, and continuous human oversight.

As CEOs and CIOs navigate this exciting new landscape, it's crucial to start small, think big, and continuously refine your AI strategy based on real-world results. By doing so, you can harness the power of AI to drive innovation, improve decision-making, and ultimately, transform your business for the better.

Call to Action

Embrace AI as a tool to enhance business architecture, not as a replacement for human expertise.
Start small, iterate, and continuously improve your knowledge base with AI's help.
Remember, AI is a tool that's meant to work for us, not the other way around. It's about making our lives easier, helping us to cut through the noise and get to the heart of what our business needs. So, let's roll up our sleeves and get to it, shall we?

Mastering Effective Business Analysis Techniques: Strategies for Enhanced Decision-Making and Growth

Vuelitics — Wed, 03 Jul 2024 11:02:00 GMT

In today's dynamic business environment, mastering effective business analysis techniques is crucial for organizations aiming to achieve sustainable growth and competitive advantage. Business analysis involves the systematic evaluation of business processes, requirements, and strategies to uncover insights that drive informed decision-making. This article explores various techniques and strategies essential for professionals looking to enhance their business analysis skills.

Understanding Business Analysis Techniques

Business analysis techniques encompass a wide array of methodologies and tools designed to analyze and improve various aspects of business operations. These techniques are instrumental in identifying opportunities, mitigating risks, and optimizing processes to achieve organizational goals.

Strategic Analysis Methods

Strategic analysis methods form the foundation of effective business analysis. Techniques such as SWOT analysis (Strengths, Weaknesses, Opportunities, Threats) help organizations assess internal capabilities and external market dynamics. By conducting a thorough SWOT analysis, businesses can capitalize on strengths, address weaknesses, exploit opportunities, and mitigate potential threats.

Decision-Making Frameworks

Effective decision-making frameworks are essential for leveraging business analysis insights. Techniques like decision trees, cost-benefit analysis, and scenario planning enable stakeholders to evaluate various options systematically. These frameworks facilitate informed decision-making by considering potential outcomes, risks, and resource implications.

Business Process Analysis

Business process analysis focuses on understanding and optimizing workflows within an organization. Techniques such as process mapping, value stream mapping, and workflow modeling identify inefficiencies, bottlenecks, and opportunities for improvement. By streamlining processes, businesses can enhance efficiency, reduce costs, and improve customer satisfaction.

Stakeholder Engagement Techniques

Engaging stakeholders throughout the business analysis process is critical for success. Techniques such as interviews, focus groups, and workshops enable analysts to gather diverse perspectives and insights. Effective stakeholder engagement fosters collaboration, aligns objectives, and ensures that analysis outcomes meet stakeholder expectations.

Requirements Gathering Approaches

Requirements gathering is fundamental to developing solutions that address business needs effectively. Techniques such as brainstorming sessions, user stories, and prototyping help capture and prioritize functional and non-functional requirements. Clear and comprehensive requirements ensure that solutions align with business objectives and user expectations.

Data-Driven Insights

In today's data-driven era, leveraging data analytics techniques is essential for deriving actionable insights. Techniques such as data mining, statistical analysis, and predictive modeling enable analysts to uncover patterns, trends, and correlations within datasets. By making data-driven decisions, organizations can optimize strategies, anticipate market changes, and gain a competitive edge.

Critical Thinking in Business

Critical thinking plays a pivotal role in effective business analysis. It involves evaluating information objectively, questioning assumptions, and making reasoned judgments. By applying critical thinking skills, analysts can identify underlying issues, evaluate alternatives, and propose innovative solutions that drive business success.

Problem-Solving Methodologies

Business analysis often involves addressing complex challenges and solving intricate problems. Techniques such as root cause analysis, fishbone diagrams (Ishikawa), and 5 Whys enable analysts to delve deeper into issues, uncover underlying causes, and develop targeted solutions. Effective problem-solving methodologies promote continuous improvement and resilience in business operations.

Market Analysis Tools

Market analysis tools are essential for understanding industry trends, competitive landscapes, and customer preferences. Techniques such as market segmentation, PEST analysis (Political, Economic, Social, Technological), and Porter's Five Forces model provide valuable insights into market dynamics and strategic positioning. By conducting thorough market analysis, businesses can identify growth opportunities and mitigate risks proactively.

Risk Assessment Techniques

Risk assessment techniques are critical for identifying and managing potential threats to business objectives. Techniques such as risk matrix analysis, risk probability and impact assessment, and scenario analysis help organizations evaluate risks systematically. By assessing risks early and implementing mitigation strategies, businesses can safeguard operations and enhance decision-making resilience.

Feasibility Studies

Feasibility studies assess the viability of proposed initiatives or projects before committing resources. Techniques such as cost-benefit analysis, feasibility analysis, and market research validate the economic, technical, and operational feasibility of business endeavors. By conducting comprehensive feasibility studies, organizations can make informed investment decisions and minimize risks associated with new ventures.

Conclusion

Mastering effective business analysis techniques is a continuous journey that empowers organizations to adapt to changing market dynamics, capitalize on opportunities, and navigate challenges effectively. By leveraging strategic analysis methods, decision-making frameworks, stakeholder engagement techniques, and data-driven insights, professionals can enhance their analytical prowess and contribute to sustainable business growth. Investing in robust business analysis practices enables organizations to optimize processes, innovate strategically, and achieve enduring success in today's competitive landscape.

Incorporating these techniques into everyday practices empowers businesses to make informed decisions, drive operational efficiency, and achieve sustainable growth in a rapidly evolving global economy.

Read More About Essential Business Analysis Techniques

The Rich Tapestry of Business Analysis - Susan Moore

Agora Insights International — Sun, 14 Apr 2024 10:23:00 GMT

Hosted by Deirdre Caren in Agora Insights' Blueprints for Success

I'm thrilled to have Susan Moore join us for episode 9 in our Blueprints for Success. In this session, Susan shares her rich tapestry of experiences that have shaped her career. Her journey into business analysis (ba) is a compelling narrative of exploration and discovery, one that underscores the notion that career paths are rarely linear. Susan's initial journey into paralegal, film direction, and art history may seem disparate at first glance, but they come together into a fascinating prelude to her eventual passion for business analysis.

Background

Susan Moore's story is a fascinating one, particularly because it's not what you'd typically expect when you think about someone working in this field . Her education in "Bachelor of Arts, Radio, Television, and Motion Pictures" and "Adult Learning" might seem worlds apart from the logical, change-driven field of business analysis. Yet, it's this very diversity in her background that provided her with a unique perspective when she transitioned into this role.

What's particularly intriguing is how Susan stumbled upon her talent for business analysis. While working at a bank, she became the go-to person for helping her colleagues navigate computer systems. It was this informal role that highlighted her ability to not only understand complex systems, Business Architecture and more, but also to explain them in a way that was accessible to others. This is a cornerstone of what business analysts do: they demystify and bridge gaps between technical and non-technical stakeholders.

Susan's move into this dynamic field wasn't a result of a calculated career move; it was born out of a real-world need and her ability to fill it. It's a reminder that career paths aren't always linear and that staying open to opportunities—even those that seem unrelated to your current skills or interests—can lead to rewarding and unexpected outcomes.

During the interview, it became clear to me that Susan's role as "Community Engagement Manager" for the IIBA brought her experience full circle.

3 Key Topics

Career Paths and Entry Points into Business Analysis

Reflecting on Susan's unexpected journey into the world of business analysis, it's clear that there isn't a one-size-fits-all approach to entering this profession. Her story is a powerful example that highlights the value of diverse experiences. It's fascinating to see how her background in the arts and her hands-on problem-solving skills with computer systems paved the way for a successful transition into business analysis. This should encourage individuals who may not have a traditional IT or business background to consider a career in this field. It's about leveraging whatever unique skills and experiences you bring to the table and applying them to solve complex business problems.

The Importance of Business Analysis in Organizations

Susan's emphasis on the critical role of business analysts in driving change is spot on. We're not just there to document requirements or to tick off boxes. Our role is to be the catalyst for innovation and to ensure that change is managed effectively. We're the bridge builders, connecting different parts of the organization, and ensuring that everyone is aligned with the overall strategy. It's a complex role that requires a deep understanding of both the business and the people within it. We're there to ask the right questions and to challenge the status quo when necessary. It's about being the glue that holds the various pieces together during times of change.

The Evolution of Business Analysis and Future Trends

The conversation with Susan also touched on the dynamic nature of Business Analysis and how it's evolving with advancements in technology. Specifically, the role of AI in BA was a topic of interest. It's clear that AI will change the way we work by automating certain tasks, but it won't make the human element obsolete. Instead, it will free up Business Analysts to focus more on strategic decision-making and interpreting complex organizational data. Understanding and leveraging AI and other emerging technologies will be crucial for business analysts to stay relevant and continue adding value to their organizations.

10 Key Learning Points:

There is no single entry point into the business analysis profession; diverse backgrounds can lead to success in this role.
Business analysts are essential in helping organizations navigate change while maintaining operational continuity.
Business analysis is not just about producing requirements; it's about facilitating communication and change.
The business analysis role is multifaceted, requiring a balance of technical skills and stakeholder engagement.
Building trust and relationships is a critical aspect of effective business analysis.
Business analysts must be adept at working with a variety of people, including those who may be resistant to sharing information.
This field is expanding, with many unique job titles and specializations emerging.
Business analysis skills are life skills that are applicable in many contexts beyond the workplace.
Being part of a professional community and engaging in continuous learning is vital for career growth.
The future of business analysis will likely involve more strategic roles and deeper integration with AI, but the core skills of analysis and decision-making will remain invaluable.

Close

Reflecting on this session, it's evident that the field of business analysis benefits from such diversity. The infusion of different backgrounds not only enriches the profession but also expands the problem-solving toolkit available to organizations. Susan Moore's path may have been unorthodox, but it's precisely this non-conformity that has allowed her to excel as a business analyst and now as a thought leader, speaker, and presenter in the industry. Her journey is a compelling narrative that encourages us to embrace the unique collection of our experiences, as they may just be the key to unlocking our potential in unexpected arenas.

I trust that you too have enjoyed this conversation and that it has inspired you to further your learning! Don't forget that Agora Insights truly guides learners to success! Let me know in the comments anything that resonated with you and any questions you have in mind.

Feel free to share in our Blueprints for Success Podcast or comment with any questions!

To get weekly videos and interviews from leaders around the world subscribe to our Blueprints for Success Newsletter on LinkedIn

Interested in business architecture and business analysis certification and corporate training? Visit our CBAP page

Learn more about Susan

Susan Moore is the Community Engagement Manager at IIBA. Before that, she was a business analysis professional with more than 20 years’ experience in finance, insurance and utilities industries working on both the Business and IT sides of organizations. Susan speaks frequently on business analysis-related topics such as career development, essential skills, and virtual communication. She writes about these topics (and more!) at TheVirtualBACoach.com. Susan holds IIBA’s Certified Business Analysis Professional (CBAP) and Agile Analysis Certification (AAC) in addition to other business analysis and agile certifications.

Susan's LinkedIn

Fabricio Laguna talks Business Analysis and AI

Agora Insights International — Wed, 06 Mar 2024 10:56:00 GMT

I recently connected with Fabricio Laguna, aka The Brazilian BA. Fabricio is a passionate and pioneering business analyst from Brazil. During our conversation, we had a thought-provoking discussion on how artificial intelligence stands to shape the field of business analysis in the years ahead. While AI promises to transform many aspects of business, Fabricio sees emerging technologies as elevating, not eliminating, the crucial human role of the business analyst.

Background

Armed with his bachelor's in computer science in the 1990s, Fabricio moved on to his MBA in Business Administration and has kept on building his portfolio into the Business Analysis space. He now has over 25 years' experience as a business consultant, instructor, and as an international speaker. It's easy to see that Fabricio is passionate about spreading the best practices and principles of business analysis to a global audience. He is currently a Senior Advisor to the President and CEO at IIBA®, the leading association for business analysis professionals where he reviews, advises and creates high quality business analysis content. He led the official translation of the BABOK® Guides v2 and v3 into Portuguese.

Fabricio is the founder and partner of Gigante Consultoria, a consulting and training firm that specializes in business analysis, project management and systems analysis. He is also a YouTuber AKA The Brazilian BA - and an online teacher, who produces engaging and informative videos, articles, classes and lectures on business analysis topics. He has the ability to explain complex things in a charming and approachable way.

As an internationally respected expert, Fabricio observes that several key adaptations, already underway, will allow business analysts to thrive in an AI-enabled future. The required skillset is shifting from technical specialization toward more holistic business acumen. Communication, adaptability and creative problem solving are moving to the fore. The scope of business analysis is also broadening beyond IT needs toward more direct strategic impact. And despite some regional variations, a global community is forming around best practices.

Fabricio shared a number of insights and learning points which I captured here in three key topics and ten learning points.

Three Key Topics:

1. Elevating Strategy Above Execution

Fabricio stressed the growing need for business analysts to focus less on completing distinct tasks, and more on actively driving desired outcomes. “If you're just motivated to accomplish a set of tests, that's not ‘very nice’. If you see the outcome on the other side, and the outcome is something that is connected to the purpose of the business and the organization, THAT VIEW changes the way you work.”

Keeping organizational priorities front and center will become increasingly vital. Fabricio also discussed the need for business analysts to elevate their level of specialization and understanding of business to meet the increasing complexity of problems.

2.Embracing AI's Potential to Augment Analysis

While artificial intelligence can automate certain routine BA functions, Fabricio believes specialized AI tools will take business analysis to the next level. Advanced systems capable of intuitively updating architecture diagrams, identifying connections between initiatives, simulating process changes and more would enable much deeper and more dynamic analysis. However, human skills remain essential to interpret the business context and validate machine outputs.

3. Cultivating Uniquely Human Skills

As new technologies transform capabilities, business analysts should hone intrinsically human strengths around creative problem solving, emotional intelligence, adaptability and strategic thinking. Fabricio noted,

“We need to level up to deal with higher, complex, business problems. We are going to talk about business on a higher level.”

AI may reshape business analysis, but the profession is not going away. Given the pace at which technology is advancing, Fabricio stressed the need for continuous learning and adapting. He shared insights on how young professionals entering the field should approach their careers, focusing on the importance of understanding the business context and being outcome driven. He shared that as he was given challenges by his bosses, he noticed that his mind was changing.

10 Learning Points:

Embrace AI as a tool, not a replacement, to enhance productivity and focus on higher-level tasks. Validate outputs through a human lens.
Discuss needs in terms of business outcomes over technical requirements. Then focus on business outcomes, rather than just completing tasks, to add real value and progress in your career.
Seek to understand why processes or rules exist before advocating change. Ask “why” questions.
Validate and verify AI outputs to ensure accuracy and maintain the human context in decision-making. Connect decisions directly back to core business objectives and priorities.
Continuous learning and adaptation are crucial in keeping up with technological advancements. Early adoption breeds advantage. Maintain an open and adaptive mindset throughout your career.
Understand the business context deeply to provide insights that go beyond data gathering and documentation.
Develop competencies in systems thinking, stakeholder engagement, and problem-solving.
Utilize AI to manage and update business knowledge assets, such as blueprints and process charts.
Recognize the importance of specialization in business understanding to tackle complex problems effectively.
Intentionally build relationships across teams, levels and organizations. Engage with the community and share knowledge to stay informed and connected.
Sharpen creative problem solving and emotional intelligence even as technical skills automate.

In closing......

Fabricio's passion for business analysis, teaching and speaking leaves a distinct impression! He brings alive that business analysis is indeed a dynamic field undergoing immense change. However, when BAs combine AI capabilities with expanding human skills, next-generation business analysts can attain even greater strategic influence within their organizations.

The conversation with Fabricio was fascinating and it provided a clear vision of the future of business analysis. It's evident that as AI becomes more integrated into our work, the role of business analysts will evolve to focus on outcomes, validation, and strategic thinking. This shift presents an opportunity for professionals to raise their skill levels and contribute to business success in more meaningful ways.

Feel free to share what resonated in our Blueprints for Success Podcast or comment with any questions!

The Do's and Don'ts of Writing a Business Analyst Resume

Sarahzain — Sun, 11 Jun 2023 05:25:00 GMT

As a business analyst, your resume is a crucial marketing tool for showcasing your skills, experience, and accomplishments to potential employers. You have the opportunity to make the best impact and secure an interview when you compose your resume. Yet, competition for jobs is fierce, so it is vital to be aware that your resume stands out from the crowd.

To make certain you have the best possible resume, remember several do's and don'ts. On the do's side, tailoring your resume to the job description, highlighting your achievements, using action verbs, keeping it concise, and using a professional format are all key elements of a successful business analyst resume. Showing that your skills match those on the job description through tailoring your resume to the position is an example of the strategies you can use to increase your odds of employment. Highlighting your achievements with metrics and numbers helps to showcase your impact and results. Using action verbs and a concise format can make your resume more dynamic and engaging, while a professional format with clear headings and fonts can help to make it easy to read.

On the flip side, there are several don'ts to avoid when creating your resume. These include including irrelevant information, using jargon, lying or exaggerating, using passive language, and neglecting proofreading. By avoiding these pitfalls, you can ensure that your resume is polished, professional, and accurately reflects your qualifications.

Do's:

Tailor Your Resume to the Job Description

The key to creating a winning resume is very carefully organizing your key skills, education, and work experience to the job you're applying for. Look for keywords and phrases that match your skills and experience, and make sure to highlight them in your resume. This will show the hiring manager that you're a good fit for the position and increase your chances of getting an interview.

Highlight Your Achievements

As much as possible, emphasize only your accomplishments on your resume. Did you increase revenue or decrease costs? Did you streamline a process or implement a new system? Use numbers and metrics to show the impact of your work.

Use Action Verbs

Start each bullet point on your resume with an action verb to make it more dynamic and engaging. Rather than saying "Responsible for analyzing data," say "Analyzed data to identify and capitalize on potential opportunities."

Keep It Concise

Your resume should not be more than two pages in length. Focus on your experience and qualifications that make them most relevant.

Use a Professional Format

Include a well-designed resume with clear headings and easy-to-read fonts. Stick to a simple design and avoid using colors or images that could be distracting.

Don'ts:

Don't Include Irrelevant Information

Each element of your job application needs to be related to the job to which you're applying. Don't include hobbies or personal information that's not related to your professional experience.

Don't Use Jargon

Break away from using terminology and technical terms that may be difficult for others to understand. Use plain language that's easy to understand.

Don't Lie or Exaggerate

Never lie or exaggerate on your resume. It's important to be honest about your skills and experience, as any discrepancies could be uncovered during the hiring process.

Don't Use Passive Language

Avoid using passive language on your resume, as it can make you seem less confident and capable. Instead of saying "Tasks were completed," say "Completed tasks."

Don't Neglect Proofreading

It's imperative to review your resume carefully for grammar and spelling errors. Even small errors can convey a poor picture to potential employers.

Summary

Tailoring your resume, highlighting achievements, using action verbs, keeping it concise, and using a professional format are all important do's when writing a business analyst resume. On the other hand, avoiding irrelevant information, jargon, lies, passive language, and neglecting proofreading are all key don'ts. When it comes to creating a resume, employing these tips will result in a high-powered document that showcases your strong capabilities to potential employers.

Author Bio:
With over 8 years of experience in writing, career coaching, and ATS-friendly resume writing, I am passionate about helping others discover their career goals and reach them. My commitment to my clients is to provide the most effective strategies for success. My expertise includes crafting compelling resumes that stand out from the competition and ensuring that each client's unique background is highlighted in an interview preparation session. Additionally, with a makeover for Linkedin profiles, I equip my clients with a powerful tool to showcase their skillset on one of the most important professional platforms available today. Whether you're looking for a new job or advancing your current career path, I can help unlock your potential through tailored advice and guidance.

The Ultimate Business Analysis Checklist for Your Next Project

Noman Jahangir — Fri, 29 Jul 2022 10:56:00 GMT

A business analysis checklist helps you stay organized while you work through projects. It includes questions that will help you identify problems in your current processes, and suggest improvements for future projects.

Understand the Problem

Before you start writing code, you need to understand what problem you're solving. This means understanding the problem space, identifying stakeholders, and defining requirements.

Identify the Solution

Once you've identified the problem, you'll need to identify the solution. You might think of a solution as something that will solve the problem, but it's also an opportunity to make things better.

Evaluate Alternatives

A good business analyst should evaluate alternatives before deciding on one option. This helps ensure that the chosen solution is the right one. It also gives you more options when it comes to implementation.

Choose the Best Option

If you're looking for an alternative to a particular software package, consider using a free trial version. You'll often find that the trial version includes everything you need to test out the product.

Implement the Plan

Once you've determined what you need to do, implement the plan. This means getting started on the tasks you identified as part of your plan. It's also important to stay focused on completing each task. Don't let yourself get distracted by other projects or tasks.

What is Business Analysis ? How it can be helpful for business to grow in right direction

Noman Jahangir — Wed, 27 Jul 2022 12:28:00 GMT

Business analysis is used to identify and articulate the need for change in how organizations work, and to facilitate that change. As business analysts, we identify and define the solutions that will maximize the value delivered by an organization to its stakeholders. We look for opportunities for new business models and new ways to work together. For example, as a business analyst in a global business, you may be asked to examine how a new venture is designed to increase revenues and maximize profitability

How Business Analysis can contribute in growth of your business and increasing efficiency of work flow in your organization. Learn how to start a business analysis exercise and apply for business analyst vacancies. The program helps you to analyze your current work process and plan your next steps in terms of growth. It also guides you through the stages of business process analysis and helps in achieving the success.

Business analysts are agents of change—professionals who analyze a business or organization, by documenting its systems and processes, assessing its business model, identifying vulnerabilities, and devising solutions. Business Analysis consulting is great art and it should be only be done by highly qualified professionals. A business analyst should work with clients, develop and implement solutions to problems, improve customer satisfaction, drive financial performance, assess and improve corporate culture, promote and maintain profitability, identify and mitigate risk, anticipate and predict opportunities, plan for and manage changes

Thanks mostly to the breathtaking pace of today's technological advancements, the 21st century's business world is one of rapid, constant change. Innovations change the way we live and work, and businesses must be able to adapt to these changes or get left behind. This is why we've launched our new, all-in-one tool, which provides all the information you need in one place:

Conclusion :

Business Analysis is very important for any sort of business . Its best to have a great business analysis to make sure your business is going in right direction.

6 Differences Between Data Exploration and Data Presentation

Zach Gemignani — Wed, 16 Mar 2022 18:55:00 GMT

There are big differences between data exploration versus data presentation. And you need to be aware of these differences as you're creating data stories and data presentations. Let’s start by defining our terms:

Data exploration means the deep-dive analysis of data in search of new insights.
Data presentation means the delivery of data insights to an audience in a form that makes clear the implications.

Your toolbox for data exploration tools is flush with technology solutions such as Tableau, PowerBI, Looker, and Qlik. "Visual analytics" tools give analysts a super-powered version of Excel for dicing data to facilitate the search for valuable insights. Flexibility and breadth of features is critical; the user needs to handle lots of data sources and doesn’t know in which direction she will go with the analysis.

Data presentation is a different class of problem with distinct use cases, goals, and audience needs. Think about the incredible data stories delivered by the The Upshot, Fivethirtyeight, and Bloomberg. These data journalists often demonstrate data presentation at its finest, complete with guided storytelling, compelling visuals, and thoughtful text descriptions. When compared to these examples, it becomes obvious that the best efforts by a data exploration tool cannot deliver high-quality data presentation.

You need a specialized solution if you really want to communicate data in ways that engage your audience. To understand the differences between data exploration and data presentation tools, let me offer six key ways that the activities are fundamentally different.

1. Audience — Who is the data for?

For data exploration, the primary audience is the data analyst herself. She is the person who is both manipulating the data and seeing the results. She needs to work with tight feedback cycles of defining hypotheses, analyzing data, and visualizing results.

For data presentation, the audience is a separate group of end-users, not the author of the analysis. These end-users are often non-analytical, they are on the front-lines of business decision-making, and may difficulty connecting the dots between an analysis and the implications for their job.

2. Message — What do you want to say?

Data exploration is about the journey to find a message in your data. The analyst is trying to put together the pieces of a puzzle.

Data presentation is about sharing the solved puzzle with people who can take action on the insights. Authors of data presentations need to guide an audience through the content with a purpose and point of view.

3. Explanation — What does the data mean?

For the analysts using data exploration tools, the meaning of their analysis can be self-evident. A 1% jump in your conversion metric may represent a big change that changes your marketing tactics. The important challenge for the analysts is to answer why is this happening.

Data presentations carry a heavier burden in explaining the results of analysis. When the audience isn’t as familiar with the data, the data presentation author needs to start with more basic descriptions and context. How do we measure the conversion metric? Is a 1% change a big deal or not? What is the business impact of this change?

4. Visualizations — How do I show the data?

The visualizations for data exploration need to be easy to create and may often show multiple dimensions to unearth complex patterns.

For data presentation, it is important that visualizations be simple and intuitive. The audience doesn’t have the patience to decipher the meaning of a chart. I used to love presenting data in treemaps but found that as a visualization it could seldom stand-alone without a two-minute tutorial to teach new users how to read the content.

5. Goal — What should I do about the insights?

The goal of data exploration is often to ask a better question. The process of finding better questions gets to new insights and a better understanding of how your business works.

Data presentations are about guiding decision-makers to make smarter choices. Much of the learning (through data exploration) should be done, leaving the equally difficult task of communicating the insights and the actions that should result.

In all these ways, data exploration and data presentation are different beasts. This is why we’ve chosen to focus on building the best possible data presentation tool, Juicebox.

6. Interactions — How are data insights created and shared?

Data exploration can be a lonely endeavor: Analysts work on their own to gather data, connect data across silos, and dig into the data to find insights. Data exploration is often a solitary activity that only connects with other people when insights are found and need to be shared. That is, when…

Data presentation is a collaborative, social activity. The value emerges when insights found in data are shared with people who understand the context of the business. The dialogue that emerges is the point, not a failure of the analysis.

Finding the Middle Ground: Data Storytelling

There is something between the extreme ends of data exploration and data presentation. We believe data storytelling lies in this intersection. Data stories aren’t entirely about “telling”, nor are they in the wilderness of “finding”. It is the opportunity to explain the data in a guided, narrative way where message meets exploration.

While there are tools for exploration (e.g. Tableau) and tools for presentation (e.g. PowerPoint), it is only recently that you’ve had the change to bring both together in one solution.

Zach Gemignani (zach.gemignani@juiceanalytics.com)

CEO, co-founder, author at Juice Analytics

www.juiceanalytics.com

Top 10 Mistakes in Requirements Elicitation

Trividh Patel, CBAP — Tue, 27 Apr 2021 05:47:00 GMT

Elicitation involves bringing out or drawing out information. Elicitation is a key task in business analysis as without proper elicitation the requirements for the solution to the business needs cannot be identified.

1. Not understanding underlying business need

Organization’s business environment keeps changing with respect to Customers, Marketplace, Technology and Marketing function. It is these changes in business environment that leads to identification of business needs at the strategic level in terms of problem or opportunity faced by the organization.

Defining business needs is the most important step in business analysis. Without understanding and defining underlying business needs, it would not be possible to identify all affected stakeholders and elicit appropriate requirements.

2. Not identifying all affected stakeholders

It is important to identify all the stakeholders affected by the given business need. If any stakeholder is identified late (or worst not at all!) may lead to incomplete set of requirements and could require a revision to requirements increasing project cost and time.

3. Treating elicitation as a phase

I have found many Business Analysts consider elicitation as a phase after planning (and before requirements analysis). But this is not true. If you think little more deeply, information gets elicited whenever we interact with stakeholders such as sponsor, domain subject matter experts (SMEs), implementation SMEs, users etc.

Elicitation is performed to understand the current state and elicit business requirements. Business requirements are used when eliciting stakeholder, solution and transition requirements. During requirements analysis, we may identify gaps which would require further elicitation. Information is also elicited from the stakeholders about solution performance after implementation of a new solution.

So elicitation is performed on an ongoing basis as long as business analysis work is performed.

4. Not asking probing questions to elicit requirements

Many novice Business Analysts assume stakeholders can proactively provide all the detailed information required for the business analysis work. Such a passive approach can be called requirement gathering but not an elicitation. Such an approach can only lead to identification of shallow requirements.

It is the job of the Business Analyst to extract or draw out the detailed requirements from the minds of the stakeholders. Business Analyst need to ask probing questions to elicit detailed requirements.

5. Not setting stakeholder’s expectations

In your career as a Business Analyst, at times you would find some stakeholder who would state their wants (whims and wishes!) as if they are their needs and expect them to be in the solution. You may find their expectations not only difficult but impossible. If you capture their wants as requirements it would be difficult later on to deliver to their expectations.

With your interpersonal and negotiation skills you need to communicate and set the right expectations.

6. Not using combination of complementary elicitation techniques

I have seen many Business Analysis teams often rely only on one technique such as interviews for elicitation. While interviews is the most effective elicitation technique but its effectiveness depends on the skills of the Business Analyst such as business domain knowledge and ability to ask probing questions.

So, apart from interviews, a Business Analyst should have knowledge of other commonly used fundamental requirements elicitation techniques such as Document Analysis, Observation and Prototyping. While a senior Business Analyst should have knowledge of advanced elicitation techniques such as Brainstorming, Focus Groups, Requirements Workshops and Surveys.

A Business Analyst should be able to understand the given situation and use combination of complementary elicitation techniques.

7. Not eliciting assumptions and constraints

Requirements are often stated (knowingly or unknowingly) based on certain assumptions which are believed to be true at that time. Requirements get impacted if those assumptions are later found to be false.

Constraints are limitations or restrictions (such as regulatory restrictions, budgetary restrictions, time restrictions etc) that restrict potential solutions to requirements. Identified potential solutions may change if there are any changes in the constraints.

If underlying assumptions and constraints are not captured for requirements, it would be difficult to assess impact on requirements if certain assumptions are later found to be false and/ or on potential solutions if constraints are changed.

8. No plan to elicit requirement iteratively

In order to elicit requirements, a Business Analyst contacts a stakeholder and requests their time. Many Business Analysts do not plan to elicit requirements iteratively and assume that stakeholders will provide all the information required for the business analysis work.

However, most of times, stakeholders are not aware why they are being contacted. After their initial meetings, stakeholder will have some idea what is expected out of him/ her. In the subsequent meetings, stakeholder is likely to give bit more detailed information. So, in order to elicit detailed information, Business Analyst needs to plan to elicit requirement iteratively.

9. Not confirming the elicited information

Work of elicitation is not over once Business Analyst is done talking to stakeholders. Business Analyst has to organize the elicited information and send it to the stakeholders for review. The purpose is to check if discussion has been properly documented and confirm the elicited information.

10. Not collaborating with stakeholders to have common understanding of requirements

When the elicited requirements are shared with stakeholders, there can be difference of opinions and conflicts between stakeholders. A Business Analyst has to collaborate, mediate and resolve conflict between stakeholders to reach a common understanding of requirements. Business Analyst should identify the stakeholder’s problems and help to identify solutions to satisfy those problems.

About Author - Trividh Patel, CBAP

Trividh Patel has about 20 years of experience in Business Analysis and Consulting in IT services industry.

Currently, he is working as Facilitator and Mentor - Business Analysis providing self-paced online courses in Business Analysis. Previously, he has worked for leading IT Services companies as Business Architect, Lead/ Sr. Business Analyst, and as IT Project Manager. He has executed several business analysis projects for reputed organizations from USA, UK, Europe, Middle East, Japan and India. He has good track record of leading team of Business Analysts to deliver business analysis projects.

Trividh Patel has done MBA in Systems and Bachelor of Engineering from University of Mumbai (India) and is Certified Business Analysis Professional (CBAP) by International Institute of Business Analysis (IIBA), Canada since March 2012. He is also Certified Six Sigma Black Belt.

For Consulting, Coaching or Guidance on IIBA Certification (or just to connect!), Trividh Patel can be reached on LinkedIn: http://www.linkedin.com/in/trividhpatel-cbap

Product Evaluation Framework for a BA

Ashish Adike — Tue, 20 Oct 2020 22:36:00 GMT

As a Business Analyst, very often we get into a situation where the Project requires multiple IT Products to be evaluated before implementation and might seek Business Analyst’s recommendation for the same. With the ever-growing range of Products in the market and the marketing promotions associated with some of the products, it’s very easy to choose the Product with most features or the most famous one. While there are various benchmarking softwares that measure the IT products from a technical performance perspective, as a Business Analyst, it is our responsibility to make sure that the right product is chosen as we are the ones who know the Business Processes closely and at the same time are equipped to understand the features of a Product that would be well suited to address the Business Requirements. While a Business Analyst may not be the final decision maker, the BA’s analysis definitely impacts the decision-making process. A structured approach to analyze the available Products would help in choosing the best suitable IT product for the Business.

Features: It is recommended to choose a Product that has Features which meet most of the Business Requirements out of the box. Although it’s difficult to find a Product which would satisfy 100% of all the required features, it’s better to choose the one with as little customizations as possible. Customizations would often mean force fitting a Product for a Business Process and may have downstream impact in future. Also, it would involve high maintenance costs to maintain a highly customized Product. As a Business Analyst, we need to provide a Business Process vs Feature mapping for each of the IT Products in question, which would enable the Stake holders to choose the IT Product satisfying the most relevant and critical Business Processes.

User Experience: As a Business Analyst we generally work closely with the Business Users and can gauge the pulse of the Users. It is important that any IT Product chosen provides a good User Experience as it would drive the user adoption and hence the success of the Project. The Business Analyst needs to capitalize the demos provided by the respective IT Products to determine the User Experience levels. Also, many IT Products are available on a free trial version, which can be utilized to get a feel of the Product hands-on before actually implementing the same.

Support: Once an IT Product gets implemented and as the Business Users start adopting it, we see a lot of enhancement requests coming from the Business Users to improve the existing implementation. Also, there might be Bugs in the Product which got missed in the testing process but arise only when the users start using the Product. In order to resolve the issues and implement the enhancement requests, it is critical to have a good post implementation support from the respective IT Product Vendor.

Ease of access: The ease with which Users can access an IT product also plays a vital role in determining the right Product. A Product which can be accessed from any web browser (i.e. Cloud) would always rank better as compared to a desktop based (i.e. on premise). It would even be better if the Product can be accessed from a Mobile device. With the work-from-anywhere concept gaining prominence, the Cloud based, and Mobile enabled Products would see an upward trend in demand.

Product Roadmap: It is important to consider the roadmap the IT Product has planned for implementing various out of box features as that would help us in planning our implementation and make decision on the level of customization that needs to be done during the initial release. The IT Product with promising features suitable to the Business Requirements needs to be given a higher priority as compared to that without a suitable Roadmap.

Although the cost and performance of the IT Product might be considered by the Management, a careful analysis of the IT products with respect to above listed parameters would help the Stake Holders in choosing the right IT Product for long term.

About the Author:

Ashish Adike is a seasoned Business Analyst with more than 8 years of experience in Business Process Analysis, Requirements gathering, Consulting, Solutioning and Project Management. Experienced in working with multiple Business functions – Sales, Marketing, Finance, Operations. Strong research professional with a PGDM focused in Sales and Marketing from Indian Institute of Management, Indore. Awarded team player with excellent learning and adaptability skills.

How to make the most of Requirement Elicitation

m_anst — Sun, 11 Oct 2020 14:54:00 GMT

What Does Success Look Like?

I challenge Business Analysts to view requestors’ requirements as an opportunity to define success. Too often, teams fall into a trap focused on requestors’ prescriptive requirements that are meant to serve as roadmaps for developers and testers. When you limit your view of requirements to this prescriptive lens, you lose sight of the overall objective and stifle the natural creativity that comes from marrying old problems to new, fresh solutions.

Why Do We Need Requirements?

Requirements unite the customer and the solution; they define expectations and how to meet them. Requirements illustrated through user stories or waterfall documentation play a critical role in shaping technical solutions and implementation steps. They also lay out acceptance criteria and use-cases for said requested change. This leads to test scenario creation and the team signing off, saying, “Yes, this is what I requested; it checks all the boxes.” Pretty standard.

But what if we offered more with our requirements? What if we connected those requirements to broader objectives the customer’s trying to solve? What if requirements solved problems customers never realized they had? These solutions ultimately lead to increases in productivity, profits and/or customer satisfaction. When you shift away from the mindset that requirement-gathering sessions are order-taking sessions for technical specifications and move toward the mindset they’re an opportunity to learn about a problem and bring it back to the group for creative solutions, meaningful technical solutions emerge. This process creates solutions that are readily (and enthusiastically) adopted by users and integrated into their processes.

How Do I Get More Out Of Requirements Sessions?

Early in my Business Analyst career, I’d leave requirements-gathering sessions thinking, “How am I supposed to do this when requestors don’t even know what they want?” These thoughts came from requirements-gathering sessions that generally went like this:

BA: “So let’s talk about what ‘xyz’ will look like and what it will do.”

Requestor: “Well, we don’t really know what it can do until you build it.”

Sound familiar? There came a point where I realized it isn’t the customer’s job to know how to give me requirements; it was my job to ask the right questions to find the problem they’re trying to solve and generate solutions. Requestors are hired to be the best accountant, lawyer, analyst, etc.; BA’s are hired to ask the right questions that drive solutions to problems, and sometimes this requires creative, well-placed questions that make the most of requirements-gathering sessions.

Eliciting Requirements

The best questions to use in a requirement-gathering session are those that create dialogue and conversation centered around problem-solving. The more people talk about a requested change, the more information can be gathered by the Business Analyst, bringing everything back to developers/testers for a solution.

Even better than a rousing conversation is a moment of contemplative silence. If you ask a question that causes customers to pause for a beat and say something like, “I hadn’t thought of that before.” you’ve asked a well-placed, creative question. These questions require customers to think through what they’re looking for, how it’ll look if it’s successful and how they’ll ultimately adopt the solution.

Here’s a list of some well-placed, creative questions that drive sound requirements, which lead to technical solutions that are readily (and enthusiastically) adopted:

What are the top problems/challenges your business faces? Why?

Why do we need “xyz”? How did we get here?

What have you tried in the past?

If this system/change looked exactly how you picture it, what would it look like?

What’s your best measure of success?

Is there anything in this process/system you wouldn’t change?

If this project/enhancement doesn’t happen, what’ll be the impact?

Finding the right time to ask any number of these well-placed, creative questions takes practice, and there’s no better time than now to start.

Just Another Way to Organize BA Quality Surveys

Mariya Kotsupalova — Sat, 10 Oct 2020 05:58:00 GMT

They say the best criteria of Business Analyst’s success are a happy customer (business) and a happy engineering team. But what does it mean? How can we break down happiness and measure it? These are precisely the questions my 8 BAs team and I tried to answer this year. The result was a surprisingly efficient pair of surveys we developed and have been using through 2020. This article will explore the core principles behind them, share their content and some options as to how the results can become actionable.

Moving Toward Quantitative Markers

The usual way to gather feedback from customers and the team is to ask them once in a while, plain and simple. In our case this would happen at the end of an assignment/project, or whenever an employee was due for a level up. There is a significant problem with this approach. I’m sure many business analysts have encountered it at some point. You ask for feedback from a developer or a product manager, and their reply is ‘everything is excellent, the communication skills are great!’. And that’s it!

Too often we are faced with a lack of understanding of the BA role. Most of our efforts are invisible and taken for granted, as a result business analysts are perceived as just ‘people who talk a lot’. This means an effective request for feedback is also an educational endeavor. The request itself should contain information about what to expect from a BA. This is why we decided to go with closed-ended questions each of which describes a key activity of a business analyst and offers to rate it.

This approach would allow for a quantifiable result, a sort of rating for each BA that could be seen dynamically through time. In our case constant rotation of BAs and POs between different streams and teams ensures even distribution of ratings - each PO has a chance to work with several different BAs over time which allows for comparisons and evens out differences in subjective ‘scales’.

Small Survey - Big Turnout

Now that we knew we wanted to design a survey, we needed to make it as efficient as possible. When it comes to surveys it is best to go small. As small as possible. So people could be lured in with a promise of a 3-4 minute effort (and this promise would be kept). And so the team actually goes through with filling it out. I can’t even count how many times I quit an online study when it tried to feed too many questions.

Our goal was to fit everything in one page, no scrolling. When we added the formal questions (which BA is being evaluated), the title and description, deducted space for the ‘submit’ button - we got room for 3-4 questions. Sounds impossible to wrap BA work into only 4 questions, does it? Well, give us a chance.

Choosing the Language

It’s not enough to just ensure as many answers as possible. The quality of answers matters too. I prefer a personalized approach to crafting questions - when people read the proposed answers in first person. The trick to it is finding major points of contact between stakeholders and business analyst’s deliverables, and wrapping them up into an informal statement. For example:“I see/read stories for the first time when I start working on them”. This is something people can relate to, internalize it and give an effective answer.

We separated out a survey for our teammates and another one for the product people. This way we could avoid being generic and place narrow targets on key expectations. Our team is Russian speaking, so naturally their survey was in Russian despite the company culture to have all correspondence in English.

Our Surveys

Having gone through key decisions that went into designing our version of BA feedback surveys, we can dig into the content.

Survey for the engineering team taps mostly into the topic of enabling delivery with INVEST user stories and efficient clarifications:

1. How well does the BA explain the business value of changes?
where 10 rate ~ ‘I always get the benefits of features for end users’, and 1 rate ~ ‘No idea why or for whom I we deliver stuff’
2. How productive are grooming sessions?
where 10 rate ~ ‘Stories are empty, I have many unresolved questions afterwards’, and 1 rate ~ ‘I can get all the details of stories and estimate them’
3. How clear is the sprint scope at the beginning of it?
where 10 rate ~ ‘I fully understand the sprint goal and what needs to be done from my side’, and 1 rate ~ ‘I see/read stories for the first time when I start working on them’
4. How well are additional questions resolved during dev/testing?
where 10 rate ~ ‘Open questions overwhelm me, there is no help from BA’, and 1 rate ~ ‘BA quickly resolves my questions and unblocks my progress’

Survey for the product team explores backlog preparation and requirements quality:

1. How do we divide responsibility for writing requirements with the BA?
where 10 rate ~ ‘The BA produces all of the requirements, I only review them’, and 1 rate ~ ‘I produce all the requirements, write stories and specs myself’
2. How complete are the requirements BA provides?
where 10 rate ~ ‘10 - requirements are very detailed from the start, they consider all dependencies and impact areas’, and 1 rate ~ ‘In majority of cases most of the scope is discovered after the work has started, work is delayed due to lack of predicted requirements’
3. How ready are the sprints at the point of planning?
where 10 rate ~ ‘We always have ready stories for 1+ sprints ahead‘, and 1 rate ~ ‘Backlog items for the sprint are empty/not ready when it comes to planning the next sprint’
4.How hard is it to review the requirements?
where 10 rate ~ ‘Everything is compact and clear, review takes seconds’. and 1 rate ~ ‘I struggle to read and understand what I'm asked to review, requirements are scattered and inconsistently formatted’

As you can see, the questions and answers are calibrated to fit our processes and deliverables. So this content may not be copy/paste-able for all cases, but hopefully it shows the idea behind this way of gathering feedback.

Timing is Everything

The surveys are sent out on a regular basis - every quarter. It establishes a habit to give feedback, helps not to put issues on hold for a long time, and provides a regular reminder of what is to be expected from a BA. New BAs get compared to old ones, core BAs get a long living evaluation that changes over time.

Another side to asking for feedback often and with consistency is an opportunity for appreciation. The surveys have comment sections which served as boxes for suggestions as well as places to put positive feedback and cheers for the hard work a BA is doing.

What’s Next?

When the survey results are in, I found it best if each BA gets acquainted with their own results. Individual feedback can be discussed with the lead/manager in 1-2-1 format to dig into the reasons for some extreme ratings - good or bad.

General rates for the whole team could be used as one of the targets for BA performance (eg overall ratings no lower than 9). The graphs can be reviewed on the BA catch up. There were times in our team’s experience with this approach when we saw some major unhappiness of the whole team with some of the aspects of our work. For example, this way we found out most of our teammates didn’t understand the sprint scope and value of sprint as a tool. When we discovered this, we gathered for a few root cause analysis sessions, held additional interviews and surveys. After this we came up with several solution options and presented them to our leadership to get a go ahead on implementation. The effectiveness of our measures was seen next quarter.

And that concludes our short tale of one BA team working out an approach to measuring stakeholder happiness. Make it short, simple, relatable, educational and regular. Hope our experience will help our fellow Business Analysts move toward better feedback and happier teams.

Mobile App Launch Checklist — 13 tips to guide you through

Green Apex — Wed, 08 Apr 2020 07:13:00 GMT

The app market has become drastically more competitive over the years and businesses are finding it challenging to be discovered in a sea of competition. Leveraging a comprehensive app launch strategy is essential for paving the way to a successful launch and a fruitful position in the app marketplace.

Mobile App Development has taken over the Digital Market in the past 5 years. It is estimated that between 2016 and 2020, yearly downloads will double to roughly 284 billion. As such, it has become increasingly important to have a comprehensive strategy and successful app launch in order to compete in this competitive landscape.

Here we give you 13 tips as an app launch checklist to guide you through the process of How to Launch an App.

1. Market Research

Running a competitive analysis involves pinning down exactly who your competitors are. It is important to gather a full understanding of who is competing in this app space, what they’re offering, and what you can do different or better to achieve success in the marketplace. Research mobile apps with similar features, themes and visual styles, and take note of how well they’re doing in the market.

2. In-App Analytics

Implementing a comprehensive mobile analytics platform can be an essential strategic tool for optimizing the user experience. Which app features are drawing users in? Are users dropping off in any particular section? How often do they use your app? Leverage insights like these to engage users with targeted and personalized campaigns that will increase loyalty and retention.

3. Beta Testing

In today’s competitive market, Beta testing your app is an important step before launching your app. The main goal of beta testing is to get real-world experience on how well your app will perform with actual users. Three popular platforms for IOS & Android testing include TestFlight, Test Fairy, and HockeyApp.

4. Marketing Plan

Marketing an app requires planning and leveraging a range of marketing mediums and techniques. It is recommended to divide your App Marketing Plan into 3 campaign phases: pre-launch, launch and post-launch.

5. Promotional Video

Creating videos provides you with the opportunity to establish a voice and communicate the value of your app. For example, a demo video allows you to offer a ‘sneak peek’ of your app and demonstrate popular features; essential for driving organic downloads.

6. Localize your App

Localizing apps for your target audience is a good business practice that requires you to add appropriate resources to your software to ensure that a given country, locale, language, or culture is supported. This means changing the language depending on location, ensuring your app is accessible to all your markets.

7. App Store Optimization

Since one of the major methods of app discovery is still through app store search, it is important to invest in App Store Optimization (ASO) strategies. ASO provides the foundations to rank higher in the marketplace; the higher an app ranks in a store the more discoverable it will be to potential users.

8. Press Releases

An article from a major tech blog is a great way to increase traffic and download rates. Remember to send information about your app’s launch to popular app review sites and any other publications you think are relevant.

9. Paid Advertisements

Paid acquisition can be expensive to use for ongoing growth, however, a limited app launch campaign is a good way to build initial awareness and downloads. Therefore, paid ads are an effective strategy to give your app the necessary boost to gain visibility during the first few days and kick-start organic growth.

10. Ongoing User Engagement

Consider how you will build user engagement with techniques like push notifications or in-app messaging. Promote engagement with special offers and discounts, customized content, reminders, and other valuable information your users are looking for. Even encourage ratings and reviews with timely and relevant rating prompts. Make sure to optimize the frequency of your marketing communications, in particular, push notifications.

11. Optimize App Performance

Social media can offer valuable insights into the user sentiment and perception surrounding your app. These channels are often the first place users go to complain when something isn’t working. It is important to monitor your app’s performance not only through in-app analytics but also through reviews and mentions on social networks, Google Alerts or any other means. This will allow you to gain a comprehensive understanding of your app’s position in the marketplace.

12. Build Store Ratings

A good average rating is one of the best ways to attract new downloads from users browsing the stores. Start with your app community, friends and family, and most importantly, your test users. Make sure to also alert your email list from your landing page about your app’s availability.

13. Plan regular App Updates

Leveraging analytics can provide insights into where and how your app can be improved, safeguarding your app’s future success. Which app features are drawing users in? Are users dropping off in any particular section? How often do they use your app? Use this information along with user feedback to develop new features and future updates that are important to your users and their app experience.

Requirement vs specification

Neetu — Sat, 07 Mar 2020 16:58:00 GMT

As a business analyst, we capture client requirements in different documents like BRD (business requirement document), FSD (functional specification document) and SRS (software requirement specification). If we are capturing the requirements in these documents, then why the document nomenclature is different? The answer is Yes. We are capturing the requirement but from different perspective. That’s why the document nomenclature is different.

Requirement refers the business need from the perspective from business user whereas the specification defines those requirements from system perspective. Requirements document what is needed whereas specifications document how to achieve the requirements.

The requirement represents the problem or need whereas the specification provides the solution to that problem/ need.

The requirement is gathered from business user/ stakeholders whereas the specification is provided by technical team keeping requirements in mind.

The input for requirement is the business users whereas the input for specification is requirement document, business users and technical team.

The output for requirement is requirement document like BRD, concept note whereas the output for specification is specification document is SRS, FSD.

The combination of complete, clear and concise requirement as well as specification is the recipe of fulfilling business user's need and to retain clients.

Top Skills That Every Business Analyst Should Have

Gaurav Belani — Thu, 18 Jul 2019 08:39:00 GMT

Are you trying to cement your career as a successful business analyst?

If yes, then let us first talk about the exact role of a business analyst.

A capable business analyst enables the organization to become agile, adaptable, and develop the ability to reinvent itself in the hyper-competitive business environment.

But how?

So, if a business is more into the traditional practices of decision making, then a business analyst can help them make better business decisions based on actionable insights. A skilled business analyst knows the data and math to help a business transform its customer’s needs into product and services.

All in all, every business needs capable business analysts to convert data into business opportunities while optimizing the existing business process for enhanced efficiency.

By now, it is clear that a business analyst has to fill many hats.

But are the exact top skills that you need to master to become a successful business analyst?

Here are some of the top skills you need to acquire in order to become a top business analyst:

1. Enhance Your Research Capabilities

If you love browsing through the internet, then you will have it easy as a business analyst because a good business analyst knows what to search and where to search.

Thorough research is all about gathering all the relevant information and analyzing it efficiently to come up with unique business solutions.

But business analysis is not all about pitching the right solutions. If anyone has a question or doubt, your research should be able to answer it with relevant data and facts.

If your research is flawed, you can rule out your ideas being taken seriously.

2. Proficiency With Numbers

A large part of a business analyst’s job is getting immersed in data and numbers. Start loving numbers to make sense of the data you have got.

The solution to any corporation’s problems are hidden in the heaps of data and statistics it creates on a daily basis. You not only need to gather all the data but analyze it thoroughly to come up with relevant business insights.

A number lover in you will never shy away from running risk assessment, statistical analysis, and financial planning, among others — some of the must-have traits in a business analyst.

Always interpret and analyze the data thoroughly to create efficient information models and the financial viability of your business solution.

3. Efficient Financial Planning

Have you ever planned your finances to run the house comfortably and at the same time, meet your future goals?

If yes, then you are unlikely to have a hard time acquiring financial planning skills in order to become a business analyst.

Naturally, business financial planning is much more complex than your regular household finance planning. However, if you already have a practical grasp of finances and economics, then foraying into professional financing wouldn’t be as difficult.

While chalking out a credible business solution, there are a few essential questions which you need to ask yourself, including:

How much your decision will cost the company?
How much time will the implementation of the decision take?
How rewarding will it be for the company in terms of revenue/profit?

You need to go through these steps judiciously, to create a successful business solution from all fronts.

After all, the ultimate goal of your job is to help your company grow while enhancing its profitability.

4. Keep Your Organization Game Strong

Too many meetings, notes, data, feedback, and so forth, can make your job as a business analyst a lot more tedious than you could ever expect.

However, this can be easily avoided if you document the whole strategy beforehand and execute it carefully.

Keeping your workplace and tasks organized can do wonders in achieving your career goals. On top of that, it will help you stick to the designated deadlines.

Thus, it is crucial to document every phase and step of the planning to keep your projects streamlined or lined up in an organized manner.

As a business analyst, make sure to organize a schedule in such a manner that it aligns with the SMART framework, which includes making specific goals, measurable goals, attainable goals, relevant goals, and most importantly time-based goals.

Source

An efficient, SMART framework-based organization can also help you to pull out even the most minuscule details within seconds. It is also the job of a business analyst to let all stakeholders know what is happening. And this is where all the recordings and documentation come in handy — when the time comes to explain the entire process of your business plan to your fellow team members or supervisors. So, keep your documentation clear and well managed to make sure everyone understands your plan.

You can also use a tool like Trello or Pipefy to keep everything organized and in place.

5. Hone Your Communication & Presentation Skills

Naturally, to become a top business analyst, you would need to hone your communication & presentation skills. After all, a large chunk of your time would be spent conversing with potential clients and brainstorming ideas with your team.

When you are not communicating in meetings, you will be shooting out emails, which again is a mode of communication. So, to excel in the field of business analysis, you need to brush up on your communication skills, both verbal and written.

Moreover, the communication carried out as a business analyst isn’t only about getting your point across but also grasping what the other stakeholders have to offer.

6. Competence at Technical Skills

While your job as a business analyst doesn’t require you to write long drawn out codes, you would still be expected to have regular know-how of coding. Occasionally, you might be expected to dabble in coding or might be required to create a graphical analysis.

Basic knowledge of programming languages such as CSS, Java, and Javascript comes in handy when it comes to demonstrating something through graphical analysis.

Other than that, you should also have competence in data analysis and should know your way around tools such as MS Office Suite, MS Excel, and more.

7. Analytical Skills

If you are gearing to become a business analyst, then you must have the potential to solve every problem that comes your way. And analytical skills are exceedingly important when it comes to finding your out of a tricky situation.

Analytical skills include clearly visualizing the problem, analyzing & evaluating it, and finally solving it using the most optimum method possible. Throw in interpretation skills and logical thinking, and you will be on your way to becoming a top-notch business analyst.

To hone your analytical skills, you need to work at acquiring knowledge in techniques such as SWOT Analysis and Interface Analysis.

Summing it all up

To conclude, a business analyst needs to be proficient in multiple subject areas and at the same time should be a great communicator. They have to wear so many hats to scale up their goals and achieve success in their job.

It is vital for a business analyst to have a mix of all the skills listed in the article, along with any other requirements that a particular organization may have.

Requirements In Context Part 2: The Functional View From 10,000 Feet

Dan Tasker — Mon, 29 Apr 2019 00:49:00 GMT

In Part 1 of this series it was stated that the overall objective of these articles is to improve the quality of requirements produced by business analysts. Following the adage that “Context is Everything” it established that a number of different contexts will be explored. And in keeping with this principle it set business information systems as the context of the requirements to be addressed.

Classic Business Functions

My very first position as a business analyst 30 years ago was with a company that had just completed an enterprise-wide planning effort.⁽¹⁾ They had gone so far as to remodel one of their conference rooms for the specific purpose of displaying the results on multi-layered whiteboards. The most prominent board displayed a functional model of the business. It was said to be a view of the company from 10,000 feet up. The functions were organised into three categories: Management, Support and Line of Business.The following diagram is a slightly simplified version of that model:

In my first article I presented the classic “Swings” cartoon. It is a classic because it has remained relevant all these years. I consider the high-level functional model presented above to be a classic. It too has stood the test of time. Throughout my years as a business analyst, working in a wide variety of industry segments and government agencies in three countries, this model has proved to be both relevant and useful.

Not all organisations utilise every one of the functions shown. And some organisations have multiple lines of business. For example Walt Disney - Film production would be one, theme parks another. In this style of model, each would have its own ‘Line of Business’ functions to provide contexts for dealing with very different products. Regardless of the numbers of lines of business, the Management and Support functions are applicable across the organisation.

Enterprise Resource Planning

Thirty years ago using a model like this to plan an organisation’s business information systems was leading edge. Database management systems had been around just a few years. Their use typically involved one-for-one replacement of application-specific files. A batch processing inventory management system would be upgraded to an online inventory management system supported by an inventory database. A batch processing sales management system would be upgraded to an online sales management system supported by a sales database. And on and on.

High-level functional models like this were used to demonstrate to the organization that a shared set of data could and should be used to support multiple functions across the business. The idea was to stop developing application-specific information systems and start developing an enterprise-wide one. Fast forward to today and this vision has become business as usual for many organisations.

It is common today for an organisation to have a relational database that holds data utilised by multiple business functions. Some of these systems have been developed in-house. Others utilise one of the commercially available Enterprise Resource Planning (ERP) systems. Probably the original and best known of these is SAP. The following is a list of integrated SAP modules that an organisation to pick and choose from:

Human Resource Management
Production Planning
Material Management
Financial Supply Chain Management
Sales and Distribution
Project System
Financial Accounting and Controlling
Plant Maintenance
Quality Management

Quite a striking correlation between these modules and the high-level functions from that 30 year old model.

High-level Requirements From High-level Functions?

This series of articles is about requirements in context. The Functional context is where we are starting. The functions from the 10,000 foot level are the most general functional context I can imagine. Could these be used to draft requirements? I can think of one scenario where they could - an organization interested in acquiring an ERP system. Here is an example of one such high-level requirement:

The system shall support Accounting processes integrated between themselves and with processes of other functions.

Each ERP function the organisation is interested in should have its own requirement naming a high-level function it wants within its integrated system. Each would be assigned its own priority. Some would likely be must haves while others might only be nice to haves. (Who am I kidding? – we all know that to business users every requirement is a ‘must have.’)

Processes within Functions

The view from 10,000 feet is an interesting functional context, but outside of acquiring an ERP system we need business functions closer to earth. Fortunately the majority of functional modelling techniques include the concept of functional decomposition. That technique used to produce the model above offered a simple three-level decomposition scheme. The things at the top level were called Functions. A level below functions were things called Processes. The third and lowest level things were called Activities.

Functions were considered to be ‘ongoing’ activities. A person working in Accounting or HR does their job year round, year in and year out. Processes in the context of this model were defined to be things that have a start and an end point. A given Function typically would decompose into 10-ish Processes. Again using SAP as an example, we see its HR module breaks down into 12 processes:

Organizational Management
Personnel Administration
Recruitment
Payroll
Travel Management
Personnel Management
Time Management
Compensation Management
Training and Event management
Wages
Personnel Development
Workforce Administration

It’s easy to envision most, if not all of the above processes having start and end points. For example, while it could be argued that Recruitment goes on continuously, in reality filling a specific position starts with some form of notification of the opening and ends ideally with a successful candidate coming on board. Here is an example of a high-level requirement utilising a Process context:

The system shall support the recruitment process including keeping records of published notifications, candidates, interviews and proof of fairness during the selection process.

Activities within Processes

The term Activity can be defined as the individual steps in a process. Visualise a workflow diagram. The boxes in the diagram that don’t themselves require further decomposition would be considered activities. The basic idea is that an Activity is that it should be simple enough that an individual is able to complete it in a single ‘sitting.’ No need to hand the work off to anyone else mid-activity or to have to wait for some other activity to complete. An example of an activity within the Recruitment process would be one called “Make Offer to Candidate.” An example of a high-level requirement ustilising an Activity as a context would be:

The system shall support keeping a record of offers made to selected candidates.

I have used a variety of functional modelling techniques from dataflow diagrams to business process modelling notation (BPMN). Regardless of the terminology used in any particular method, I have found the definitions of the three functional levels presented above to be excellent guideposts for both functional modelling and drafting requirements.

Next Time – Project Scope as a Context for High-Level Requirements

Gathering of requirements is typically managed within a project, and part of managing a project is establishing its scope. Requirements are expected to address the things within this scope. Next time we will look at scope and how high-level requirements can be derived directly from it, and actually as part of the scoping effort.

(1) The enterprise-wide planning methodology utilized by the company described was called Strategic System Planning (SSP) developed by Robert Holland.

How did I achieve my CBAP?

Trividh Patel, CBAP — Sat, 09 Mar 2019 12:19:00 GMT

At first, I wanted to tell people how they should go about getting their IIBA certification. But then I thought the best way to do this is by actually telling “how did I achieve my own CBAP?” So, friends here is my story.

I started working as Business Analyst in 2002. I have used multiple elicitation techniques (such as interviewing, workshops, focus groups, etc.) and different requirements analysis techniques such as process modelling, use case modelling, user stories, prototyping, business rules analysis, non-functional requirements analysis, business case development etc. I have had good experience in business analysis projects working for clients worldwide.

By 2011, I already had about nine years of experience in business analysis when I have decided to go for my CBAP certification.

First thing I did was to check if I was eligible to apply for IIBA CBAP certification. So, I studied IIBA CBAP handbook and understood that IIBA evaluates business analysis experience in terms of 6 knowledge areas and I was supposed to have total of 7,500 hours of business analysis work experience and minimum 900 hours in at least 4 knowledge areas to apply for CBAP certification.

So, I studied IIBA BABOK guide version 2.0 and understood various business analysis tasks under each of the 6 knowledge area. This was the latest IIBA BABOK guide at that time. I started analysing my project experience from the IIBA perspective. I have listed down all the projects I have worked in my career and identified different business analysis tasks and activities I have performed and figured out number of hours I must have spent in each of those tasks and activities. I aggregated number of hours as per knowledge area and also calculated total hours of my business analysis experience.

To my surprise, I had well over 7,500 hours of business analysis experience and over 900 hours in all the 6 knowledge areas.

Next thing was to get 2 professional references and out of that one was supposed to be current contact. So, I approached my career manager and explained him benefits CBAP will bring to the organisation as well as to me. He gladly agreed to provide recommendation. Next, I approached single point of contact from one of the client organisation and he too agreed to provide me recommendations for CBAP certification. I have also contacted various colleagues from past projects and companies and got their buy-in in case IIBA would want to audit my project experience.

Next thing was to ensure I fulfil professional development in terms of contact hours. I understood from CBAP handbook that training can be in any area directly related to business analysis. As I already have had enough business analysis work experience, I thought of attending full time lean six sigma certification training. Please note that the training provider was NOT an Endorsed Education Provider or an EEP and still it was accepted by IIBA. Many people don’t know that IIBA does not mandate training provider to be an EEP but mandates training to be relevant to the business analysis and must be instructor led classroom or virtual live (for CCBA and CBAP application). However, for ECBA application training can be online without instructor.

After attending training, I have submitted online application on the IIBA website. I have provided information such as my education and work history details such as Project Name, Start and End dates, project Description, Total BA hours, Project contact details and various BA activities performed. I have also provided professional training details and two professional references.

After submitting application, I have paid application fee online. Within a week I received confirmation email from IIBA that my application was approved and I am supposed to pass the certification exam in 1 year from the date of approval email.

So I started preparing on my own for CBAP certification. I have studied IIBA BABOK guide at least 4 times. I have correlated concepts in the IIBA BABOK guide to my actual project experience. I have also figured out ways to remember concepts such as involvement of stakeholders and use of techniques in various business analysis tasks. It took me over 6 months to prepare.

Once I was confident I have identified nearest venue available for taking the exam and paid the exam fee.

I have registered and scheduled my CBAP exam for 15-March, 2012.

The exam venue was almost at one and half hour drive from my home and this time was subject to traffic conditions. So, I tried searching for a hotel near exam venue but there was no hotel nearby. So, I have approached a friend whose house was fortunately nearby the exam venue and he gladly agreed to let me stay overnight.

So, I stayed at my friend’s place and next day I reached venue on time. I showed my exam conformation emails and proofs of identification to the exam supervisor. I used provided username and password to logon the exam application.

I started attempting CBAP exam but soon I have started experiencing noise from other desks. I requested people and also to exam supervisor but it was of no use. Just then I remembered that I have ear plugs. Use of ear plug really helped to significantly reduce the noise and let me attempt exam without much disturbance.

I again started attempting questions. I have flagged certain questions for which I was not very confident. After attempting all the questions, I revisited flagged questions and took calculated risks and tried to figure out the best possible answer. After doing this, I still had about 20 minutes so I quickly browsed through all the questions and answers. I found couple of mistakes made while selecting my choice of answers. I made corrections and submitted my answers for evaluation.

Within just 30 seconds, I got message on my screen that I have successfully passed my CBAP exam!

I got email from IIBA confirming the same. I was also informed that my name will be included in list of CBAP recipient on the iiba website and also that I shall receive my certification kit in another 2 months time. I was also told that from now on I was licensed to use CBAP in my name and in my communication.

Well, that was my story and I am sure you too would have yours one day. All the Best!

About Author - Trividh Patel, CBAP

Trividh Patel has over 17 years of experience in Business Analysis and Consulting in IT services industry.

He has worked for leading IT Services companies as Business Architect, Lead/ Sr. Business Analyst, and as IT Project Manager. He has executed several business analysis projects for reputed organisations from USA, UK, Europe, Middle East, Japan and India. He has good track record of leading team of Business Analysts to deliver business analysis projects.

Trividh Patel has done MBA in Systems and Bachelor of Engineering from University of Mumbai (India) and is Certified Business Analysis Professional (CBAP) by International Institute of Business Analysis (IIBA), Canada since March 2012. He is also Certified Six Sigma Black Belt (CSSBB).

Trividh Patel can be reached on LinkedIn: http://www.linkedin.com/in/trividhpatel-cbap

Requirements in Context Part 1 - Just Know It!

Dan Tasker — Mon, 22 Oct 2018 20:23:00 GMT

I have long been a believer in the saying “Context is everything.” As a business analyst dealing with business users, understanding the context of the topic of discussion is essential. In thinking about what constitutes quality requirements it occurred to me that there are a number of additional contexts that play a role. Examples include the organizational maturity level (from Informal through to Optimized) and delivery context (green fields through to package acquisition).

This is the first in a series of articles about business requirements. My primary objective is to help business analysts improve their elicitation and documentation of requirements. With an increased awareness of multiple contexts I believe that the quality of the requirements documented can be improved, and subsequently lead to the better design, development and implementation of business systems.

Mark Twain is credited with saying, “Everyone talks about the weather, but nobody does anything about it.” The equivalent saying in the IT context would be, “Everyone agrees that good requirements are essential, but nobody does anything about them.”A perfect illustration of this is the classic IT cartoon “The Swings”:

What is not funny about this cartoon is that the situation it depicts is as true about business systems delivered today as it was when the above version was published. Over 40 years of struggling, and most often failing to meet user expectations, in spite of unimaginable improvements in technology.

I have no illusions that what I intend to present will magically make it all better. But these articles are at least my attempt to do something about it. If you are reading this it means you are interested in improving your BA skills. Hopefully learning about the impact of different contexts on requirements will lead to that.

The Business Information System Context

I find it virtually impossible to take off my business analyst hat. Any time a family member or friend mentions that they want something – a new car, an electrical appliance, I immediately go into ‘requirements mode.’ I start asking questions intended to help them focus on their thinking in order to lead to making the best choice. It occurred to me that it as I begin to present the various contexts related to requirements that I should set the context for this series of articles. The context of requirements that I intend to focus on is business information systems. And while a complete information system includes a hardware and a network aspect, the requirement contexts that will be discussed will not include these technical aspects. The requirements contexts will focus on business analysts interacting with business users to deliver the functional and information components of a system.

Please note that when I use the term ‘system’, from a requirements perspective that doesn’t mean that every requirement will result in a computer-based solution. Having gathered requirements a subsequent exercise is to determine which of them will be given automated support and which will be left as manual processes.

Functional and Information Components

The earliest “computers” were primarily electronic calculators. They allowed complex formulas to be broken down into individual computational steps. Having expressed these steps in a language the computer could understand the resulting instruction set was ready to receive the data to be manipulated. The end product was a set of calculated results.

When businesses began using computers their objective was to maintain data about their business. Computational requirements were minimal. Simple things like adding or subtracting deposits and withdrawal amounts from a customer’s account balance. The original computerized business systems all performed their functions by reading in batches of data, operating on each record as it went through the system, and producing individual results before the next record was processed.

With the advent of database management systems and access in ‘real time’ to computer applications, more and more business processes could be supported by computers. Today virtually every office worker has a computer on their desk. And thanks to wireless networks and portable devices workers (and customers) outside of the office have access to the information they need when they need it.

With the focus of business information systems being the support of functions that capture and utilise data I offer a variation on the Nike slogan “Just Do It”. The objective of the business information systems we gather and document requirements for should be “Just Know It.”

Functional Context / High-level Requirements

Having established the context for these articles to be business information systems, the journey itself will begin in the next article. In it I will present a technique I have used for many years to help establish the functional context for a requirements gathering effort. The more common term for this functional context is “Project Scope.”

I will also discuss the possibility of combining the scoping exercise with the producing of high-level requirements. The result of doing this reduces that requirements task down to hours rather than days (or weeks). This will be the first of several demonstrations of the strength of applying the thinking that “Context is everything.”

Next article: Requirements In Context Part 2 - The Functional View From 10,000 Feet

Difference between ECBA CCBA and CBAP Certification

Ann P — Sat, 11 Aug 2018 06:45:00 GMT

What’s the difference between ECBA CCBA and CBAP Certification?

Which certification should I pursue ECBA CCBA or CBAP?

How do I know which certification is right/suited for me?

There are so many certifications I am completely confused which one to pursue?

Can you please guide me on which certification should I go for?

These are some of the common questions I come across very frequently after IIBA has released the new multi-level certification scheme in the second half of 2016.

The four certification levels are deigned to suit the needs of business analysis professionals at various different levels.

Level 1 – ECBA (Entry certificate in business analysis)

Level 2 – CCBA (Certification of capability in business analysis)

Level 3 – CBAP (Certified business analysis professional)

Level 4 –CBATL (Certified Business Analysis Thought Leader)

Primarily aimed at beginners to senior and seasoned business analysis professionals these certifications test the BA knowledge and skill of professionals at varied levels.

Here’s a snapshot of the various certifications presented in a high level comparative manner:

IIBA Certification Schemes Overview

Parameter	ECBA	CCBA	CBAP
Full Form	Entry Certificate in Business Analysis	Certification of Capability in Business Analysis	Certified Business Analysis Professional
Caters to	Recognizes individuals entering the field of business analysis	Recognizes BA professionals who have 2-3 years of BA experience	Recognizes BA professionals who lead and have over 5 years of BA experience
Target Audience	Individuals entering the BA profession New graduates Professionals aiming to switch over to a BA career	BA professionals having 2/3 years of experience Developing BAs, Hybrid BAs - PMs, Testers, QA, Change Manager, Tech Lead	Aimed towards BA professionals having 5 years of experience Seasoned BAs,BA Consultants,Trainers, Business analysis,Systems analysis,Requirements analysis or management, Process management, Consulting
Eligibility	·No Work Experience required ·No Knowledge Area expertise ·Minimum 21 hours of Professional Development Training in the past four years	·Minimum 3750 hours of BA work experience aligned with the BABOK Guide in the last 7 years ·Minimum 900 hours in each of two of the six knowledge areas or minimum 500 hours in each of four of the six knowledge areas ·Minimum 21 hours of Professional Development Training in the past four years ·Two references from a career manager, client or CBAP recipient	·Minimum 7500 hours of BA work experience aligned with the BABOK Guide in the last 10 years ·Minimum 900 hours in each of four of the six knowledge areas ·Minimum 35 hours of Professional Development Training in the past four years ·Two references from a career manager, client or CBAP recipient
PDU	21 in last 4 years	21 in last 4 years	35 in last 4 years
References	Not needed	2 from a career manager, client or CBAP recipient	2 from a career manager, client or CBAP recipient
Focuses on	·Requirements Analysis and Design Definition -24% ·Elicitation and Collaboration – 20% ·Requirements Life Cycle Management – 20% ·Business Analysis Planning and Monitoring – 5% ·Strategy Analysis – 5% ·Solution Evaluation – 1% ·Techniques -12.5% ·Underlying Competencies – 5% ·Business Analysis Key Concepts – 5% ·Business Analysis & the BA Professional- 2.5%	·Requirements Analysis and Design Definition – 32% ·Elicitation and Collaboration – 20% ·Requirements Life Cycle Management – 18% ·Business Analysis Planning and Monitoring – 12% ·Strategy Analysis – 12% ·Solution Evaluation – 6%	·Requirements Analysis and Design Definition -30% ·Strategy Analysis -15% ·Requirements Life Cycle Management – 15% ·Solution Evaluation -14% ·Business Analysis Planning and Monitoring – 14% ·Elicitation and Collaboration – 12%
Exam Pattern	·1.5 hours long ·50 multiple choice questions. ·Basic multiple choice that test the candidate’s knowledge and understanding	·3 hours long ·130 multiple choice questions. ·The questions are scenario-based (i.e. candidate must do a bit of analysis to arrive at the answer)	·3.5 hours long ·120 multiple choice questions. ·The questions are longer cases (1 to 1.5 Pages of information). ·Multiple questions about the case.
Rewrite	Twice within one year of approval with no wait time	Twice within one year of approval with no wait time	Twice within one year of approval with no wait time
Exam location/ Mode	Online Proctored exam via PSI from any location	Prometric test center available in all major global cities	Prometric test center available in all major global cities
Rewrite /Retake fees	85 USD – Members 195 USD – Non Members	250 USD – Members 375 USD – Non Members	250 USD – Members 375 USD – Non Members
Application Fee	60 USD	125 USD	125 USD
Certification Fee	110 USD for Members 235 USD for Non Members	325 USD for Members 450 USD for Non Members	325 USD for Members 450 USD for Non Members
Recertification fees	NA	$85USD for members $120 USD for non members	$85USD for members $120 USD for non members
Membership Fees	Region 1 – 125 USD – USA, Canada, Australia, New Zealand, Europe, UK Region 2 – 85 USD – Singapore, Malaysia, Middle East Asian countries.. Region 3 – 55 USD – India, Pakistan, Thailand, Tanzania..

I sincerely hope this will help you in giving a good snap shot of the IIBA multi-level certifications overview.

Using this information you can decide what would be the right certification for you.

--------------------------------------------------------------------------------------------

If you like my posts please like/share/comment and spread the word in your network.

Would love to hear from all professionals here, please leave a comment with your feedback.

You can see all my posts in LinkedIn here

I write on Business analysis and other management related concepts/tools and day to day ideas, you can reach me at Ananya.pani@gmail.com

Requirements traceability : What, why and how

LN Mishra, CBAP — Wed, 04 Apr 2018 09:39:00 GMT

Traceability is one of the lesser understood aspects of business analysis. It is indeed quite hard to maintain good traceability unless automated. This is why BABoK® warns us being theoretical about traceability.

In this article, I would like to explain traceability concepts with help of an example.

BABoK® definition of traceability:

Traceability is the ability to look at a requirement and others to which it is related, linking business requirements to stakeholder and solution requirements, to artifacts and to solution components.

Traceability identifies and documents the lineage of each requirement, including its backward traceability (derivation), forward traceability (allocation) and its relationship to other requirements.

Traceability ensures that the solution conforms to the requirements. It also helps in managing scope, risk, time, requirements changes, cost and communication. It can be used to detect missing functionalities or to identify whether the implemented functionality is supported by a specific requirement.

Reasons for creating traceability are:

Assist in impact analysis for requirements changes.

Ensure requirements coverage: Understand how business objectives are implemented. Business objectives not traced to detailed components have not been analyzed and hence not included in the solution.

Requirements allocation.

Relationships

Derive

When one requirement is derived from the other. Stakeholder requirements are derived from business requirements. Solution requirements are derived from stakeholder requirements.

Depends

One requirement can be implemented only if the other has been implemented or easier to implement if the other is implemented.

Satisfy

Relationship between an implementation element and the requirements it is satisfying.

Validate

A relation between a requirement and its test case to validate whether the solution fulfills the requirement.

Let’s take a practical example of a requirement to list all products on an eCommerce store (such as AdaptiveUS.com/eStore)

Requirement

To list products in the ecommerce portal with their price

Derived from (Parent requirement)

Enable e-commerce for business

Dependent requirement (Prerequisite)

Payment gateway to collect payment from customers

Satisfied by (Allocated to Solution component)

Store front end

Validated by (Tested by test component)

Test cases to test store functionality.

This is a simple template to capture requirements traceability. You may transpose the same to handle multiple requirements in the template.

About me
I am a professional BA, trainer, coach and author.

If you like my posts please like/share/comment and spread the word in your network.

Would love to connect with fellow professionals.

You can also reach me at LN@AdaptiveUS.com

About my organization, Adaptive US
We provide training, study guides, question banks, necessary PDUs for ECBA, CCBA, CBAP certifications.

For more details, please visit www.AdaptiveUS.com

What has a greater impact on Digital Transformation: Enterprise Architecture or Business Architecture?

EA Learning — Tue, 13 Feb 2018 21:25:00 GMT

Around this time 12 months ago Gartner predicted that half of EA Business Architecture initiatives in 2018 would focus on defining and enabling Digital Platform Strategies. While there hasn’t been follow up research to prove whether this prediction has come true, anecdotal evidence would suggest that the real situation is pretty close.

In the research Betsy Barton, Vice President and Distinguished Analyst at Gartner stated:

“The increasing focus of EA Practitioners and CIO’s on their business ecosystems will drive organisations further toward supporting and integrating business architecture. This is to ensure that investments support a business ecosystem strategy that involves customers, partners, organisations and technology.”

The core output of a Digital Transformation, from an IT perspective, is the development of supporting digital business platforms. However, with the growth of cloud based services success in this transformation process is less a technology challenge and more a Business Model challenge. Digital Transformation can provide an opportunity for organisations to do business in a totally different way. But the fundamentals of business in a digital and traditional world remain the same. To run a sustainable business you need to deliver a product/ service to customers that meet their needs in an effective and efficient manner and ensure that you continue to evolve that product/ service so that it continues to meet customer needs into the future. And you need to make a profit doing it. So you need to have a Business Model that achieves this.

Enterprise Architecture is very good at defining, and bringing a semblance of order to, the complex ecosystems that make up a business, particularly from a technology perspective. However, business architecture is what brings it alive. This is what Gartner calls this business-outcome-driven Enterprise Architecture, which emphasises the importance of understanding the business and how it executes on its value streams.

TOGAF practitioners will proport that Business Architecture is an inherent part of the Architecture Development Method (ADM), which is true. However, I would argue that Business Architecture should be the key driver of the ADM to deliver a successful Digital Platform Strategy, rather than focussing on some of the more traditional governance elements of Enterprise Architecture.

The really interesting aspect of the Gartner research is that Ms. Burton advises that one of the keys to success for the implementation of successful digital platform strategies will be the ability of organisations to integrate with other businesses digital platforms. While this will be a significant technical challenge the key to deriving real business value will be ensuring that the platform and integrations align with the organisations strategic intent and support its value streams. In this context Enterprise Architects will not only need to understand the business drivers and outcomes required by their business but also the needs of their partners in the digital ecosystem.

This ability to support the innovation agenda that is driving Digital Platform Strategies has also seen the rise of a new Architecture skillset, design-driven architecture. Gartner advises that “design driven architecture will allow organisations to understand their ecosystem and its actors, gaining insight into them and their behaviour which will allow organisations to develop and evolve the services that they need and consequently deliver on their business objectives”. In effect it will allow Architects to be more customer/ human centric in their designs to better meet the increasingly complex needs of customers/ stakeholders. The key skillet that will be leveraging is Design Thinking or Human Centric Design.

With millions of dollars being pumped into Digital Platform Strategies the pressure on Architects is significant. They need to be able to manage the need to innovate organisations Business and Operating Models, often within Agile Development environments, while ensuring the interoperability of these platforms with other players in the organisations ecosystem. In addition they need to delight their customers/ stakeholders and in the private sector deliver a profit! With the continued development of Cloud Based Services the challenge of delivering these objectives by developing successful Digital Platform Strategies will be less of a technology challenge and more a business challenge.

When I initially posed the question of which discipline, Business or Enterprise Architecture, has a greater impact on Digital Transformation it wasn’t to say that both weren’t important. However, if you look at the underlying value proposition of Digital Transformation it’s about doing business better and more efficiently by leveraging technology. To fully realise this promise the business models and value streams that deliver these outcomes need to be clearly defined and tested based on customer/ stakeholder needs (Design Thinking) before the development of the technology platform to support them. It is for this reason I believe that Business Architecture will have a greater impact on Digital Transformation initiatives than Enterprise Architecture!

Article written by Scott Comte, General Manager of EA Learning.

The Business Analyst and the Cloud

Limor Wainstein — Mon, 25 Dec 2017 18:17:00 GMT

The age of cloud computing is now so firmly established that research firm Gartner predicted by 2020, a corporate "no-cloud" policy will be as rare as a "no-internet" policy is today. In the same press release, Gartner went on to predict that spending on compute power sold by cloud providers will exceed that of compute power sold and deployed into traditional enterprise data centers.

Given the ubiquity of cloud computing, business analysts need to prepare for the cloud and understand how it affects their roles. As valuable problem solvers within all organizations, business analysts will help to streamline and optimize business processes for deployment in the cloud. Below are five things you need to know about the cloud if you are a BA—these insights will help better prepare you for your company’s likely move to some form of cloud computing service. You’ll find out about motivations for moving to the cloud, some popular products offered by cloud vendors, such as AWS Amazon EFS, and much more.

Why Move to the Cloud?

Given its explosion in adoption over the last few years by all kinds of businesses, it’s helpful to understand the motivations behind the buzz about cloud computing.

Perhaps the most important reason for its surge in popularity is cost-efficiency. Without a cloud solution, organizations must fund data centers, servers, hard drives, network capacity, security, and infrastructural upgrades. Moving to the cloud reduces, and, in some cases eliminates many of these costs. In the cloud, you typically pay only for what you use, and infrastructural costs are much lower because there are fewer IT assets on-premises to maintain or upgrade.

The second consideration is scalability, meaning the ability of a computer application or service to handle growing workloads by adding more computing resources or upgrading existing computers. Scalability is difficult in traditional on-premise IT systems. However, in the cloud, scalability is as simple as requesting more cloud computing instances or requesting your provider to upgrade existing instances.

Cloud Computing Options

Organizations typically use three broad types of cloud service:

Software-as-a-service (SaaS). The most comprehensive option, SaaS outsources infrastructure, software, and its underlying platforms (OS, databases, etc.) all to the cloud vendor.
Platform-as-a-service (PaaS). The middle ground cloud computing option in which the vendor provides infrastructure and essential tools such as databases and operating systems. Businesses then build custom applications which run using the provided infrastructure and platform.
Infrastructure-as-a-service (IaaS). This option provides core infrastructure in the cloud while the organization manages everything else.

Cloud Vendors

A significant number of vendors provide cloud services for enterprises, and it can be tough for businesses to choose the right option for their use case. Perhaps the most well-known of these vendors is Amazon Web Services (AWS), the current market leader in cloud computing according to IDC.

AWS offers several types of cloud solution, including Amazon EFS, which provides cloud storage on Amazon EC2 cloud computers, and is commonly used for analytics, Big Data, and web serving. There is also Amazon S3, which is low cost storage typically used to distribute static web content or host static websites. To dive a little more deeply, see this post about managing Amazon EFS volumes in the cloud and how to get started with EC2.

Other options outside of AWS include Microsoft, which has IaaS, Saas, and PaaS options, and IBM Cloud.

Cloud Computing Issues

Just because cloud computing is so popular either as a hybrid solution (combining on-premises and cloud services) or as a fully-fledged cloud-only solution, this does not mean it’s without concerns.

Security

A 2012 breach of popular SaaS service Dropbox resulted in the compromise of 68 million passwords, and there have been other security breaches since. Such incidents lead to speculation about the security of cloud computing services and how cloud hackers might get access to customer data or halt mission-critical business processes.

Despite these incidents, the cloud is very secure, and most cloud vendors enforce rigid security measures including access control, encryption, and authentication.

Outages

When a business relies on cloud providers to help provide its mission-critical apps and services, any outages experienced by the cloud provider can send businesses offline too. A 2017 Amazon S3 outage caused problems for many websites, making some completely inaccessible (more details).

Businesses can combat potential outage issues by using disaster recovery services. It’s also worth noting that disasters can happen to IT centers on-premises so this is not an issue unique to the cloud.

Business Analysts and Cloud Computing

As a bridge between the problems cloud computing attempts to solve and the implementation of cloud technology, the BA has a vital role in ensuring an optimum cloud computing strategy, whether hybrid or cloud-only.

The BA helps to:

Identify which processes or services should be moved to the cloud
Outline the required governance and policies to ensure the integrity and security of sensitive organizational data
Help businesses understand the levels of service required by its cloud providers to ensure any cloud solutions achieve what businesses need from them
Indicate how best to monitor cloud performance and identify personnel responsible for this monitoring

Business analysts are the best-suited professionals at any organization to fulfill the above duties and ensure a smooth integration with cloud technology.

Conclusion

Cloud computing will provide more exciting opportunities for business analysts to flourish and use their skills to do what they do best—solve real business problems. Whether your business opts for a SaaS solution like Salesforce, or one of Amazon’s IaaS/PaaS services such as Amazon EFS or S3, the above information should ensure adequate preparation for the main concerns you’ll need to deal with as a business analyst in the age of cloud computing.

When is Security not a Non Functional Requirement?

Peter — Tue, 22 Aug 2017 18:12:00 GMT

If you are building a reusable Security Product tool to specifically address Security Technical Implementation Guide (STIG) Findings, should the requirements be considered Non Functional Requirements or Functional Requirements?

For example if there are a number of STIGs such as:

The minimum password length shall be 15 characters
The maximum password length shall be 30 characters
The password shall contain at least one of each of the following types of characters
1. Numeric Character
2. Uppercase Alphabetic Character
3. Lowercase Alphabetic Character
4. Special Character (!,@,#, etc.)
The password shall be changed a maximum of every 60 days

should I add them to the Functional or Non Functional section of my Requirements Document.

Add your answers and thoughts in comments below:

A New Metaphor for Business Analysis

Ronak Sanghavi — Sun, 25 Jun 2017 17:29:00 GMT

Current State

For many years now, the most commonly used metaphor on Business Analysis has been the “Bridge”. However, in recent past, some in the BA community have started revisiting the metaphor resulting in a debate on how relevant it is. Of course, the value business analysis can provide for an organization does not depend on how it is described. So does that mean we should ignore this debate? I don’t think so. A metaphor is a powerful tool to develop useful mental models, and efficiently create possibilities for value-creation.

My take on this debate is that both sides are right. This is so, because the state of business analysis is not uniformly mature across countries and work cultures. For instance, BAs in North America are more likely to find the “Bridge” metaphor limiting/restrictive because of how the role has matured in the past decades. On the other side, for most BAs in emerging economies the “Bridge” metaphor still provides aspirational value.

So, what is behind my ambivalence? Most common interpretation of the metaphor is that it connects business and IT stakeholders. My take is that it is a bridge between the problem domain (current state) and the solution domain (future state). This take on the “Bridge” metaphor is not limiting, because it includes all levels of business analysis maturity - from strategy analysis to solution evaluation, and everything in between.

A New Metaphor

Not that there is anything wrong with a debate, but it is time for a new metaphor. I would like to share with the BA community a metaphor which has shaped my business analysis journey, especially in the past 5 years since I co-founded a business analysis startup. I look at business analysis as a “GPS” to move from the current state to the desired state. In other words, it guides stakeholders to achieve project success and organization goals. This metaphor is more inclusive (represents all flavors of BA role) and accurate (represents full potential of the discipline).

Let us look at the elements (features) of the conventional GPS system, which make it so useful; and how business analysis aligns with them.

#	GPS Feature	How Business Analysis aligns with GPS Feature in Projects
0	MAP – a useful representation of the landscape	· Build a representation of the business and IT landscape through research and analysis of industry; market forces, including competition; organization; operations; and current IT systems
1	CURRENT LOCATION – ability to determine current location in the context of the MAP	· Provide appropriate context for a project by customizing and sharing with stakeholders the relevant business and IT landscape · Define current state of the problem domain, and frame the problem statement
2	DESTINATION – assistance to select destination, e.g. a highly rated Point of Interest	· Help organizations prioritize IT investments through business cases · Facilitate definition of the desired state through solution scope and requirements specifications
3	NAVIGATION – real-time navigation to help reach destination most efficiently	· Facilitate selection of the best solution to meet requirements · Facilitate shared understanding of requirements through requirements transition, continuous communication, traceability and change management · Identify, engage, collaborate and coordinate with stakeholders; and support them to achieve desired solution

Any single feature, from the list above, is useful by itself. The “GPS” metaphor on business analysis is inclusive and aspirational enough regardless of the maturity of the BA role in a country, work culture, organization, or even an individual project. Furthermore, by symbolizing the positive global impact GPS has had on humanity, this metaphor helps us quickly and robustly communicate the power and value of the business analysis discipline.

My Experiments with this Metaphor

The “GPS” metaphor is not just a concept, which I made up for the purpose of writing this article. This mental model has fueled my passion, and shaped how I have approached business analysis in the latter part of my career. In fact, all service and solution offerings of my company are built on this mental model. I have received favorable and instant acceptance of this metaphor every time I have pitched my company’s solution portfolio to potential clients. I have also received positive feedback in training and coaching interactions from individuals when I have used this metaphor to provide more clarity about business analysis.

Your turn

I would love to hear your views on this. I hope that your active and constructive participation in this dialogue will not only help me crystallize my thoughts on this topic, but also give the BA community a new metaphor to actuate and communicate the potential of our profession.

Challenges in Implementation

Sanjay Yadav — Mon, 20 Mar 2017 12:34:00 GMT

Challenges in Implementation:

I’m a strong believer of putting finishing touch to any initiative. Project Initiation is always tough and complex and need lots of research but if BA is unable to give the finishing touch then he is not done yet. So, I thought to put few of my views, challenges and observations during Implementation phase that I have faced. BABOK does a great job in explaining the Strategy Analysis and Solution Evaluation however real time challenges are most of time unspoken. As a Product based Business Analyst I often face few challenges which are altogether different than the last one.

Stakeholder involvement and Governance: This is one of the challenging and critical step to find out the exact governance of stakeholders. Each stakeholder interest towards the product implementation do impact the final stage of the product. Lack of interest do hamper the product implementation. So if any stakeholder has less interest so its critical to know the reasons. Sometimes its better too to know why if any stakeholder shows more than needed interest. Maintaining correct and verified Project Charter does help in this.

Over Expectation: Customers are always demanding and they should be as they are the one who are paying for all these, however as a Business Analyst you must be very smart to distinguish the expectation and over expectation of client because over expectation often makes your system more complex to use by the end-user and customer which ends with spending more bucks and gaining less.

Deadline and Release Planning: As a business analyst make sure that circumstances don’t control you and your team, and you deliver your project successfully even if you don’t meet the original deadline. The art of prioritizing the solution requirement helps you to pass through. You should keep some time in buffer so that you have availability of resources to fix the unwanted issues or the deadlock condition in approval or implementation.

The Acceptance: Most of the time I have found more involvement of people in acceptance compared to when you do the brainstorming or focus group. Sometimes customer say that they aren’t looking for this altogether. So, providing a view of your product before acceptance saves you. Do not ever try to give more than requirement (without information), customer will treat it as a bug because they haven’t requested it. Though sometimes over-explanation saves.

Training: Sometimes it happens that everything is as per the client request and you are at a better stage to close the project but you end with hearing that there is no such benefit by the new implementation. I have observed that sometimes the user is not aware of the new feature or do not know how to use the new feature at all. So, Training to right people is very important. Sometimes you should move desk by desk to see if customer the using it fully.

Getting feedback: Learning from your mistake is very important however knowing what went perfect is important too. Feedback from customers is very important to learn and grow as a business Analyst.

There are number of other challenges that do a Business Analyst phase. I would love to hear.

9 Traits of an Incredible Awesome Leader

Paul Crosby — Wed, 07 Sep 2016 14:34:00 GMT

There are hundreds of traits that make up a good manager, but here are the top 9 skills we recommend for a business analysis leader - or any leader in general.

1. See Design as a Differentiator

Anyone can design but not everyone designs well. Who cares? Frustrated users care. Seeing design as important sets you apart from all other business analysts that don’t’ give it a second thought. Build interfaces that are practical and good looking. Don’t see design as something someone else does – it something you as a business analyst can do.

2. Build the Vision – Be Adaptable to the Approach

Build consensus and a strong vision for the outcome. Share the vision of the outcome for the project far and wide to gain a common understanding within your organization on the vision. Share frequently and share often. Implementing the vision can take a thousand paths. Be adaptable. The way to realize your vision isn’t going to be on a clear cut path – there will be many forks in the road. Understand that planning is important in elicitation of requirements and design, but it’s volatile and subject to frequent changes. Create a planning approach the ensure your path forward is well understood, but balanced against overly complex and detailed planning.

3. Understand Your Customers & Users

At the heart of the vision lays the core user. These are the users that interact with your applications, systems, and processes every day. Without them everything just fades away or collapses. Identify your core users then profile them to build meaningful interfaces and processes targeted directly at them. Target your communications and marketing strategies for your vision and product to them very specifically. Knowing how to turn the heads of your core users and get them to support your vision is critical to your success. Once the core users are on board all the other types of users will fall into place. Build a fan base. Even an accounting application can have a fan base. Fans support you and give you new ideas to build your vision. Treat your fans well and they will support you through thick and thin.

4. Don’t Plan More Than 18 Months Out

Long term planning past 18 months is impossible. Markets and organizations change too rapidly to have road maps or long term planning past 18 months. The second you produce that 5-year plan it’s obsolete. Keep fluid in your planning to reach your vision. You may need to re-group or re-think your approach several times over. It’s better to be aware that you need to change your approach and planning frequently than to forge ahead thinking it will be set in concrete.

5. Plan, Perform, Evaluate, Adjust

We talked about planning above. Here’s a cycle that works:

A. Plan It Out – choose your path to reach your vision. Keep a Requirements Work Plan (RWP). Build the consensus and understanding on the tasks you are performing for the project.

B. Perform the Plan – don’t let the RWP sit idle. Work to carry out the tasks outlined and meet the dates you assigned yourself. This builds trust.

C. Evaluate continuously – be aware your best-laid task list could change in an instant. Be aware of other activities or projects that are pulling you away from meeting your plan. Check your progress against the plan and know when things are going off plan.

D. Re-Plan Proactively – get yourself back on track and re-plan frequently. Keep your team aware of the re-planning process and why re-planning was needed. Frequently re-planning is better than falling too far away from the plan and missing expected dates. There are no hard and fast dates no matter what the project manager tells you.

6. Don’t Rely on One Method of Communication

Email is tried and true but not the only way to communicate out your status, projects success or potential changes to users. Everyone is overloaded with email. Find a new channel of communication to keep your project’s vision and potential organizational impacts visible. Personal notes, open houses where anyone can swing by during a 2-hour period to ask questions, and even hallway meetings are a great way to communicate.

7. Focus on Opportunities – Destroy Problems

Only focusing on problems takes your eye away from opportunities that will bring better results. Choose the bright side and be optimistic in your attitude. New opportunities will present themselves. Be prepared to take advantage of them. Find problems and get to the root cause – then destroy them. Don’t focus on trimming a problem’s branches or cutting it down instead, kill at the roots. Don’t let the problem linger around or give it the ability to grow back.

8. Carefully Build the Team – Build Strong Relationships

If you get the chance to choose team members, then choose carefully. Listen to your gut feeling and don’t bring on board resources that you don’t or can’t trust – even if you can’t explain why. It’s hard to put into words sometimes why you don’t trust. Choosing the right members for the team will make or break the vision. Maintaining a team is equally important. Spend time every week celebrating or gathering the team informally outside of the daily stand-ups or weekly status meetings. Try to hold that meeting somewhere different and fun. Even moving to a different conference room will oddly change the team’s perspective – especially if they are trapped in the same war room every day. Always be grateful and reach out to say “Thank You”. Remember those different communication channels? Don’t always email – try a hand written thank you card or just ask them out for a coffee to say thanks for their help. Building the strong relationships get you through the tough times in a project.

9. Know Your Strengths – Outsource Your Weaknesses

You are not everything to everyone. Figure out your strengths and what you are good at. Personality tests give you a hint but ask around. Listen to what your colleagues, friends, and family believe your strengths are. Play to your strengths – you're strong at certain things for a reason. Know your weaknesses – then outsource them or engage someone to help you overcome them. Ask for help. For extra credit build the project team knowing the strengths and weaknesses of everyone on the team to balance them out.

So here’s the truth. As leaders and contributors in the Business Analysis field, these are the skills we need every day. They are also the skills that founders of companies hold.

Check out more great blogs at Bob the BA today!

Are You Being a Design Illusionist?

Paul Crosby — Wed, 07 Sep 2016 14:31:00 GMT

As business analysts, we are often in the fray of designing. Whether it’s a user interface, report or data fed from one system to another; business analysts create interfaces with human beings and systems. Our design choices impact users and other systems in a very real way. This power can go unnoticed even in our own minds.

Have business analysts become illusionists and pickpockets? Both these skill sets require some of the same sleights of hand. The illusionist uses the blind spots and limits of human vision to fool us. If you haven’t had an opportunity to watch the show called “Brain Games” – give it a whirl. It does an excellent job of explaining how an illusionist can fool our sight and point of view. For the pickpocket, it’s the distraction of a conversation, a tap, or a bump to set your mind off in the opposite direction of where you should be focusing while a sleight of hand takes your wallet.

Are we as business analysts playing a role of illusionist and pickpocket when designing our interfaces? Let’s look at interfaces (such as screens and reports) in a broader sense. An interface in my mind is the presentation or “stage” an illusionist would use.

We all believe we have choices and freedom. Everyone in the western world most firmly believes they have great freedom of choice in being able to do whatever is desirable, affordable and of course legal. You can go just anywhere and do just about anything. But when confronted with a system, website or application with a menu of choices, we fail to see how we are hijacked.

We rarely ask the questions:

(1) What is NOT in the interface? Or why are these my only choices?

(2) What is the purpose or goal of this interface? What is it used for?

(3) Why are these options higher or lower on the interface? More visible or less visible as other choices?

(4) Are these choice empowering me or just distracting me from doing what I need to accomplish?

If you have every used a search engine like Google or an application like Yelp, you get a sense choices are made for you and only certain things are being presented for your attention. I have been told the nearest restaurant or gas station is several miles away – all the while standing right in front of one! I usually chalk it up to “well they must not have gotten into the database yet” but now I’m leaning more to thinking I’m being fooled by the choices I’m presented.

Back in the ancient days at the dawn of computerized civilization – something like 40 years ago for you youngsters – computers were called mainframes. Mammoth monsters that would manage large amounts of data, electricity and generate a lot of heat. They required a forklift to move and had to be water cooled.

In those ancient days of computer myths and data Gods, there was but the humble green screen. To get to all the crap stored in that giant mainframe required you to issue the magic commands. By locating the secret words in the sacred text called “Command Line Reference,” you could instruct the mainframe beast to perform feats of great wonder. In other words, there was a giant three-ring binder with all these commands listed in alphabetical order that you were required to memorize and type correctly. The mainframe didn’t tolerate spelling mistakes, and there was no such thing as auto correct. No Google-like “Is this what you mean?” ever appeared on the screen. Even the help key which was supposed to provide assistance rarely did. This was the world of complete freedom from “the menu”. All the commands were in the book and available and granted they didn’t cover everything you wanted to do, but they did cover a lot of stuff you needed to perform. Yes, you had to memorize a boat load of command line syntax because the mysterious book appeared and disappeared as it desired, but you never felt limited rather you just felt a need to search for the right command.

Enter the age of the personal computer. For simplicity, the command line went away. The mouse was born. There was nothing more entertaining than watching grown men in a room holding the mouse with both hands tightly but gently trying desperately to get that arrow moving in the right direction on the screen. “This mouse thing will never catch on” they grumbled. Suddenly the command line was gone, and menus or buttons presented to us. These were your options. Your only available commands. It didn’t take long before I missed my giant 3-ring binder of commands that gave me all the power.

Over time we became to believe that only the commands we could see were the ones of importance. We would become less and less frustrated at not seeing the things we needed. We are restrained by choices of actions presented. Our perception came to be that if it wasn't presented, it wasn't available.

So let’s take this into the modern smartphone age. The other night friends and I were out at a restaurant having a great conversation. The restaurant was closing because it wasn’t that busy and the owner wanted to call it a night. We asked each other the question “let’s continue this conversation – where should we go?”. We all pulled out our smartphones pulling up Google, Yelp, and the other thousand apps on our smartphones looking for a place that was open late. This searching went on for 15-minutes or so. Now I can be a bit impatient with technology and frankly don’t always find it of much help in situations like these. I quit my search letting the others wade their way through the digital data flowing around with smartphones. Then I looked up.

A beautiful park lay right before our eyes across the street, and we didn’t even see it. We believed our only options to find some place were those our smartphones provided. Did those applications tell us about the park? Not one. How about that food truck with the fabulous desserts? Nope. Not a single one. Our illusion of having choices was broken. Sure we got a lot of options, but it was all about the pictures of the menu or comments from other people that distracted us from answering the exact question “Where should we go to keep talking?”. The menu or interface design didn’t answer our actual question at all. It created the illusion of choice by presenting a small subset of options. All said and done the park was bug-free which is a miracle in Minnesota some evenings. Dessert and conversation continued for hours in the street lamp lit park.

As business analysts or designers, it is easy just to limit user choices to a few as possible to send them down a well-defined and perfectly groomed path. But does that answer their question? How many times have you wanted to say “Siri – lead the way to a great evening with my friends!”. The response from Siri is, “I’m sorry I don’t’ understand what you are asking”.

There are a thousand paths to getting or achieving something. No matter how hard you try to make it simple, it just winds up being even more complicated. Or worse the real thing you need is hidden somewhere because someone felt it wasn’t’ important enough to warrant a button. Some of the best interfaces look very simple on the front end and have a rich set of commands just slightly inside of the interface. As a business analyst and designer, we need to give our users or community a rich experience with our application. Are we the illusionist – forcing users down only one path? Our accounting system has several ways in which to generate an invoice. From a customer contact screen, main menu, sidebar and I’m sure more options remain hidden in the accounting interface. As I watched the finance, customer service, and sales people utilize the user interface with the simple task of generating an invoice, I noticed something important. Not everyone went about taking the same path.

Sales people always went to look at the customer inquiry screen first before generating an invoice. Individuals and their contact information were more important to them, and they would update it before moving on to creating an invoice. Customer service created invoices from the order screens as they were more focused on shipping products. Finance folks just clicked on the main menu option.

Know your users. They each have a story and a way of performing tasks that make sense to them. Think about their “persona” and what they need to accomplish. There is no single path to creating an invoice. Develop a list of capabilities and make sure they are not “hidden” from view. If it all doesn’t fit on a screen, find ways to expand the options for display when requested. Don’t fear including two buttons “Create Invoice” and “Add Invoice” which go to the same screen if it makes more sense to a broader audience of users. It is more about clarity for your users then consistency in terms.

What has a dinner in the park taught me? Smartphones are not as smart as we think they are. Everyone thinks they have choices, but don’t always see the most obvious choice because the choice is not presented in a way the user would understand. Question the choices presented and determine if they are the only choices.

Yes, I still miss my green screen terminal. CMD-1 key forever will mean “useless” help, and a blinking green bar on a black screen will always be a symbol of the endless possibilities to mistype ridiculously long string of text that doesn't make sense to anyone. And that huge 3-ring binder filled with commands-a-plenty works damn good propping the door open.

For more good stuff on business analysis and leadership, check out the blog at Bob the BA.

Pablo Picasso and Scope Visualization

Paul Crosby — Wed, 07 Sep 2016 14:28:00 GMT

Scope – the last frontier. We are on a mission where no business analyst has gone before. To explore strange new diagrams and to have the project scope clearly understood. Extra credit to those who remember which TV show that was from! Scope and context are the number one reason business expectations about a project are not met, and projects fail.

Let’s face the reality. Projects today are more complicated. In this integrated and connected world of systems long gone are the days of the quick and easy change. Our organization’s architectural diagrams look like the tombs of Egyptian Pharaohs. Symbols and shapes connected by lines that fill the wall of an entire room. Even trying to explain the diagram to someone can take days.

Projects now require more involvement by more people. Our systems and processes are so complex and integrated it’s too difficult for one individual to understand them all. Stakeholders are flung across the globe speaking many different languages. Top it off with organization’s taking on hundreds of projects at the same time. Keeping track of each project’s scope and impacts to the organization are difficult to comprehend. It’s no wonder why understanding the context of a project’s scope is the number one reason why projects fail to deliver value. They lose sight of the project's vision and goals in our complex systems and processes. Everyone is one a different page. We wind up spending a lot of time trying to get stakeholders, sponsors, and team members to have a clear understanding of scope.

So it’s no wonder that scope and context are the number one reasons projects fail. How can you get an entire project team moving in the right direction? Not understanding the scope and context of a project leads to all sorts of time being spent on just figuring out what we are trying to accomplish with a project.

So how do we get everyone on the same page? By that, I mean the same page in the same book!

It’s time to visualize scope. Scope places the boundaries around where the entire project team will work. Bust out that context diagram. Getting a clear common understanding of scope and business expectations leads to better projects that deliver real value. Is that user story a complete representation of the project boundaries or scope? Maybe not. The EPIC or a bunch of user stories combined would be closer to the bulls-eye. A picture is worth a thousand words. Visualization of scope is worth its weight in platinum as it creates the vehicle to ensure a common understanding of the project scope.

Scope visualization isn’t just about a context diagram. That’s certainly a great tool, and I blogged about it previously. Don’t get me wrong – I love my context diagrams. Pushing the envelope a bit, I have used infographics to display project scope in place of context diagrams. In a recent server upgrade project, I was updating the operating systems and consolidating over 1,300 servers. Sticking 1,300 servers on a diagram was an exercise in futility. There just isn’t a big enough piece of paper to display them all. So I pictured things at a higher level. I presented each server farm as a farm – yup cows and red barn with Farmer Joe. The size of the farm was based on the number of servers on that farm. Server farms were in specific locations, so this gave the project team a visual representation of which sites were going to be impacted more heavily. All of this was based on estimates from doing a high-level scan. Remember context is high level.

In each barn was an icon that represented a group of servers. There were three groups: leave it alone, upgrade it and consolidate then retire it. I didn’t have exact numbers or server names at this point, but I knew the servers would be divided into those groups by talking with stakeholders. Servers were put into groups based on our best guess.

In the kickoff meeting, this was a great tool. Sponsor and stakeholders understood in the scope of the project. Yes, they wanted to know more. Everyone wants to know the details, but we were just starting out. Everyone walked out of the room with a pretty good understanding of the scope and estimated size. Many were surprised at the volume of servers in each farm. Overall the infographic did an excellent job of setting the stage for the project visually. All on one PowerPoint slide.

The idea of scope visualization is to present a single page to provide a high-level overview of the changes the project will make to systems, processes, and people. That’s no easy task. Taking the complex and making it simple is powerful. It creates a better shared understanding of the project.

The business wanted a global CRM solution, but all they got were pigeons and index cards. Yeah, that is why context is important.

Context doesn’t just talk about scope – it also sets business expectations about the outcome of the project. It’s important that all throughout the project to keep the communication channels open on what is happening with the scope and how the design is being implemented to meet the scope.

I take the concept of the context diagram a little farther than how most folks typically use a context diagram. You know me always pushing the envelope. Context diagrams usually explain the end state or the outcome of the project. They show the scope of a project outcome.

Building on a good thing, I like to build a context diagram of the current environment at a high level. Even at a high level, I’m often surprised at how differently stakeholders, sponsors, and team members view the current state. It’s a great tool to get everyone on the same page for the starting point. Having everyone on a different page for what we currently have will cause a few issues down the road in understanding the final destination. Knowing where you are starting from is a powerful thing when to explain where you want to end up in the future state.

Taking this concept even a bit further (and perhaps more uncomfortably) into the desired state. Not many projects look at the desire of the stakeholders and sponsors. The desire is stated in the project request form or project charter. The sponsor and stakeholders put together a vision of the expected outcomes in these documents. A context diagram of the project charter or request which elaborates the vision is a powerful thing. It ensures what is being asked for is understood.

Don’t re-invent the wheel. Many times I take the current state diagram and just highlight the areas that are changing. Use color to highlight the add, modify or removes based on the context diagram for the current state. Color visually explains where the changes are visualized to occur.

Now you may think I completely lost my mind at this point. Fear not I’m taking a step even further. I take the context diagram that shows the desired state (based on the project charter or project request) and determines what is feasible. Everybody wants it all but the teleporter to zap you across the globe for a break in Paris hasn’t been built yet. Reality always steps in and dictates what is feasible. Taking the context diagram I will highlight the areas that are NOT feasible. It’s a great way to level set the expectations of the sponsor, stakeholder and project team members.

So when in the project life cycle does all this context stuff happen? Ideally, it should happen before the project starts at a very high level. Wouldn’t it be great to start a project where everyone understood and was in complete agreement about the project outcome? You can bet it would save a lot of time running around trying to get everyone on the same page. Typically, the context is set at the start of the project.

As you move through the project, more and more understanding is acquired. Details need hammering out and there is ALWAYS change to the project. Has anyone ever worked on a project with absolutely zero change? If you have, you are leading a very charmed existence. I’m jealous. Context diagrams can help evaluate how a change would impact the project. So forget about laminating them and hanging them on the wall. They are living breathing documents that will change throughout the life cycle of the project.

The pitfall is that architects and others might expect diagrams that show the smallest of components. Don’t fall into that pit. Your job is to communicate the boundaries clearly but not make it so complicated a rock scientist from NASA can’t figure it out. Detail is important for design but scope context requires things to start at a very high level and be decomposed into more information. Context is simple with enough detail to make it clear.

Break out your inner Pablo Picasso and get creative. Find a way to display context or scope in a visually appealing manner. Color can help bring greater clarity. Highlight areas in different colors to bring focus to them. If a system is risky or substantially impacted by the project scope, highlighting is a technique to denote that risk. Black & White isn’t your friend. Studies have shown that color diagrams – even with a small amount of color – are more memorable.

Check out Bob’s blog for more good stuff on business analysis and sign up for our newsletter today. Bob the BA offers the Badass BA workshop and Enterprise Analysis workshop which covers this technique in more detail.

8 Ways to Be a Badass Business Analyst Employee

Paul Crosby — Wed, 07 Sep 2016 14:23:00 GMT

Being a badass isn’t about intimidation or trying to be something you simply are not. It’s about knowing who you are and using your strengths to drive forward. So let’s look at a few of the ways to be a badass in business:

1. Passion for Your Craft Is a Powerful and Infectious Energy

Showing passion for your work in always willing to learn more and explore new ideas in your profession shows you are a badass. A badass isn’t afraid to learn something new about their craft. Always be willing to step up to the plate and show what they are good at performing. Sitting back and doing just the expected is not the badass way. If you are amazing at drawing diagrams, then use them frequently in your work.

A few years ago I was managing several projects. Things were not going all that well on these projects, and I knew something needed to be done to get them on track. Holding up the schedule and pointing at it wasn’t solving the problems we were facing. I decided to explore different approaches and ideas by contacting others outside the company for their advice and doing a little reading up on handling scope problems in projects. I learned a lot of scope management techniques as a result of that exercise and was able to apply them to my project. My boss at the time noticed I went out of my way to figure out new approaches, and I was fearless in learning new techniques about my craft. By learning and stepping out to explore new ideas I was able to move the project forward and save the project from failure.

2. Keep Positive

Nobody likes a negative person constantly interrupting, jumping to conclusions and always complaining. Keep a “we can do this” mentality even in the toughest of times. The measure of a badass is in being able to be calm, think clearly and project positive possibilities. When the whole world is crashing down, don’t be the one saying “Well that figures.” Instead be the one saying “This isn’t the greatest situation, but we have some great opportunities here to make positive changes.” See the good in situations where others cannot. Be the person that says “I’ve got a few ideas that might help in this situation, and I would like to bounce a few of them off of you.”

One of the toughest projects I faced was working with remarkable requirements, but a development staff that either didn’t want to or just could not fulfill those requirements with the current system in place. The team quickly got very negative at all the challenges that we were having in development. Everyone’s attitude soured and nothing was getting accomplished. The project was on its way to failure. So I threw a pizza party. My entire team thought I lost my marbles, and it was time to call the men in white coats to pick me up. Pizza does wonders for putting a team in a better mood. I told the team I understood the situation was bad and acknowledged that the company wouldn't accomplish anything without their skill sets. I purposefully turned the conversation from a negative (What is going wrong?) and made it positive (What ideas do you have to make it better?).

This was no easy task. I had to work very hard to move everyone’s attitude toward the positive after months of being in the negative. I was direct in telling them “Nobody wants to work on a negative team – it sucks. What can we do right now to make this team more fun and productive?”. After that hurdle had been cleared, it got easier to involve everyone in making team changes and design changes to the project. I kept telling myself that no matter what happens I will remain positive. The team’s attitude evolved over time. Many team members and company leaders repeatedly said that they could always count on me for being positive and finding solutions to problems.

3. Know Your Craft and Tools

A badass doesn’t just stop learning the basics of their craft or tools. They are constantly expanding their toolset and keep current about their craft. It’s too easy to get comfortable and begin to feel there is nothing more to learn. A badass grabs any opportunity to learn new things.

In my past life, I was at a company where I was pigeon-holed. I did such a good job at data warehousing and reporting that no one wanted to let me try anything new or different. Damn, I was bored out of my mind because every day was the same thing over and over. Sure I was learning new things about data warehousing and reporting, but I never stepped out of that area into other areas. So I forced the issue a bit and shoehorned my way into a call center application. It made sense for me to pursue it because that new system would be feeding the data warehouse. I went a little further than just worrying about data and started moving into user interface design and workflow for the new call center application. It was a great experience to use the knowledge I had in data warehousing and reporting to build better user interfaces and business processes. After the project had been finished, I was seen as being useful in business process as well as data warehousing. The door opened, and I got the chance to work on a whole new set of projects. Don’t be afraid to step out of bounds – you just might be valued for it.

4. Make Life Better for Others

A badass knows that improving the lives of their team members by continuously being focused on improving the way things are done is important. Being innovative to solve problems the team is experiencing in the day to day operations is just as important as solving project problems. Process improvement is powerful. A badass understands it’s not about single glory but helping others to achieve great success.

You always hear “It’s not my job” especially in large companies with well-defined roles. A badass looks for ways to improve the working conditions and tasks their team performs. It can be a simple as creating a library of past project documents that can be reused or finding a new way to perform time reporting that is easier. Whatever it is, a badass is looking for ways to improve processes at every moment and isn’t afraid to suggest well thought out changes.

5. Know Thyself Well

Know thy strengths and know thy weaknesses. A badass is aware of their strengths, and they know their weaknesses and limits. In today’s corporate culture, we focus on weakness. By focusing entirely on weaknesses, performance appraisals have become more like firing squads. A badass knows to play to their strengths and to engage others to help them out with their weaknesses.

There are certain things I have discovered I’m genuinely bad at. Anything that involves molding clay into an object is bound for disaster. Both of my skiing trips ended in an uncomfortable tree hugging. In business I know I’m a driver – be quick, be bright and be gone. It wasn’t until half way through my career that I realized how that impacts others who are not drivers. By understanding how I lead and act, I was able to soften my approach and be more collaborative with others. My driver mentality is a strength that others recognize. I can snow plow through massive amounts of data to give clear direction. I communicate quickly and concisely on projects.

Play to your strengths at all times. If you know you are weak in an area, then go out and find someone who is strong in that area to balance you out. If you get the chance to put teams together, look at each others strengths and weakness to balance them all out. Forget about finding that perfect all around team member without weaknesses. They don’t exist.

6. Don’t Always Say What They Want to Hear

Being a butt kisser or yes man is not the path of a badass. If you are always saying what others want to hear from you, they will never fully trust you because they can’t tell if that’s what you honestly believe or if you are just being a parrot and repeating everything back to them. A badass understands that conflict is part of life, and sometimes you are going to have to say what doesn’t want to be heard.

The trick here is saying it without being annoying or a jerk. If there is an elephant in the room, then say there is an elephant in the room. A badass knows that hiding the obvious doesn’t make it go away but rather gives it greater power. Address it quickly and directly. Forcing the issue is a one-way ticket out the door. Follow the “Toot, Toot and Salute” rule. Bring it up once and if there is no response or disagreement then re-group your thoughts. Bring it up again and if there is still no response or disagreement, then accept it and move forward.

7. Ask Questions, Challenge and Dig Deep

No one likes to be challenged. It puts them on the defensive right away. A badass understands that challenging an idea is an art form and that challenging helps bring deeper understanding and meaning. A badass knows that without asking questions and digging deep, the entire problem cannot be understood fully.

Nobody likes to feel they are being interrogated. Be fearless but considerate in digging deep. Verify your thinking and dig deeper with “Help me understand” questions. Share what you have learned to validate it. Be appreciative of the different perspectives and gather them all up to see the greater picture more clearly. The most significant problems I created for myself was making assumptions and never validating those assumptions. You may not be able to validate or challenge at that specific moment. Write it down, reflect on it and determine if you need to challenge it. Challenge appropriately and thoughtfully. Step back and schedule a challenge at a later time.

8. Lead Even When Your Job Title Doesn’t Say Leader

A badass leads even when it isn’t in their title or role. They had the initiative and don’t shy away from leading in their craft. They don’t wait for someone else to schedule the requirements meetings, they step up to the plate and schedule them.

In the many times, I have played the role of the business analyst I’ve stepped outside my role a bit. I’m probably more comfortable with that then other business analysts in that I have been a project manager. My favorite is when I’m told how long it will take to gather requirements. You know those meetings were without being consulted the project manager has decided how long you as the business analyst will take to gather requirements and complete the design. When I’m in the business analyst role, I often will put together a requirements work plan outlining the steps that will be taken to elicit requirements and build the design. I review it with my stakeholders, project team and sponsors. This runs face first into the project managers desire to create and control the schedule. By gaining common agreement on tasks for the requirements and design process, the schedule can be more reasonably created which in turn helps the project keep to its timeline and budget. Is there a negotiation? Oh yeah – there will be lots of negotiation with the project manager, sponsors, and stakeholders on what will be done and what won’t be done. Step up to leading the task and schedule you will be expected to adhere to for the project.

For more good stuff on business analysis and leadership, check out the blog at Bob the BA.

Business Analysts should be top of mind

Edward M Ngubane — Tue, 16 Aug 2016 20:45:00 GMT

What is the role of the business analyst? A typical response to this question is that he is a bridge between IT and business. Often this view is reinforced by textbooks and training material covering the business analysis domain. The reality is that there is still much confusion about business analysis as a discipline.

In my opinion, this view is flawed, and it inadvertently leads to a limitation of how most business analysts see themselves. It renders them incapable of offering real value to the businesses they serve, and more importantly becoming top of mind to their business owners. I would argue that business analysts are a triangle connecting three parties: business, IT and the customer, instead of being a bridge connecting two sides.

In some cases, organisational structures further exacerbate the limitation of the business analysts’ ability to deliver value. This happens when business analysts fall within the IT reporting lines and get assigned to various businesses from time to time. This structure has unintended consequences. Business analysts see themselves as IT resources first, and business resources second. At the face of it, this might seem like an insignificant side effect. However, I would argue that it is at the core of the mindset that is adopted by the business analyst. It is responsible for the ‘us’ and ‘them’ situation where the business analyst refers to the business he is servicing as ‘them’, and the IT team to which he belongs as ‘us’.

So how does the business analyst become top of mind?

There is a definite need for the business analyst to be closer to the business and to be a true ambassador of the customer. I have seen that in most cases, business analysts who report to IT struggle to make a ‘business’ mindset shift. Wearing the business hat and ultimately that of the customer within the IT structures often makes the business analyst feel like he is betraying his IT colleagues.

Confidence is required for the business analyst to change the reporting dynamic. Reasoning with the IT team as to why it makes business sense and not necessarily IT sense takes courage. Business may want to adopt a phased approach in rolling out a solution versus the IT team’s big bang approach. The business analyst will need to address this with the teams in a confident manner.

An essential area of understanding for the BA is the customer’s pain points and how a particular solution will solve them. Knowledge of the market, the client’s competitors and which projects will yield the highest ROI is a prerequisite. Questions such as which projects are strategic or need to go ahead from a compliance perspective, and how to reach a particular market need answers.

A business analyst may need to explain to the technology team why his business requires certain information from his customer or potential customer over others. A full understanding of the business rules is needed, for instance, an RSA ID field as a mandatory field but not a Passport field as an option. Alternatively, why one type of design will have an adverse effect on the customers’ user experience and possibly result in a huge customer drop off through the journey map.

It is an undeniable fact that business analysts should have a fair, if not solid, knowledge of what is going on in the technology space. Requirements will need to be documented and in turn translated into system functionality. The BA is likely to spend most of his time in system design sessions with the IT teams to bring these requirements to life. If the BA has no technical background, he is likely to end up frustrated when engaging with the system developers, solutions architects and the rest of the IT team members.

Having an understanding of IT will help to earn the respect of his IT colleagues as well as to gain acceptance. At the end of the day, real collaboration is necessary to deliver value to the customer.

Talking of value - never before has the demand been so high for businesses to deliver value to their customers using technology. The advances in mobile technology and the ubiquity of smart mobile devices has created an exponential increase in the demand for mobile apps as platforms to service customers. Organisations are almost forced to digitize their service offerings through mobile apps – or they will lose out to their competitors.

Moreover, techno-savvy customers are demanding convenience and searching for time-saving ways to get what they want. Services have also been commoditized and delivered via systems. The business analyst is required, now more than ever, to marry IT and business to enhance the customer experience through self-service channels via mobile devices and kiosks. Therefore, understanding the technical arena, while showing a solid grasp of the business has enormous benefits.

What skills should the business analyst have?

While the above criteria are crucial for the business analyst to master, there are specific skills needed to achieve top of mind status. The first of these skills is the ability to listen attentively in what is called active listening. To do this successfully, one needs to learn to switch off the internal monologue. This usually happens whenever we are listening to someone else. It requires attentive listening without thinking about your response while the speaker is still talking.

The value of getting this right is that it will allow the business analyst to pick up on and appreciate the nuances inherent in the priorities between IT and business. It is important to note that these parties have different mandates to carry out within an organisation. A common misconception is that IT should not or will not dictate to business. However, the reality is that if business has no clue of what is happening in the IT world, then this dictation happens all the time. A technically informed business analyst who actively listens to both parties stands a better chance at success.

Also, if inactive listening is applied then the finer details that inform the different mandates may be missed, and this might result in conflicts and confusion. Listening actively to both parties during the requirements elicitation and/or JAD sessions can save the business analyst much pain in the future. Active listening is not a talent, but a skill that can be learned and developed.

It is important to note that during system development, especially within an environment that uses a waterfall methodology, a lot of clutter and noise can easily creep in between the time of the initial request (from business) to the time of the final delivery of the solution (by the IT team). A business analyst needs to use active listening skills to identify what is said (to ask for confirmation), what is implied (to ask for validation) and what is not clearly stated (to ask for clarification) to remove this clutter or minimize its impact.

A business analyst tends to be a leader from the side meaning that no official authority has been given to lead within an organisation. However, coordinating and managing roles and responsibilities between the business, IT team and the customer puts a huge leadership role on his shoulders.

Good leaders rely on influence, and as such a good business analyst needs to develop and master this art. To be top of mind to his stakeholders, the skill of encouragement and influence may shift the viewpoint of others. However, the ability to change minds does not happen by chance; it comes from the respect which the business analyst has gained through demonstrating a strong understanding of the business and domain skills. The latter also builds confidence to educate his or her colleagues about the discipline of business analysis.

The ability to deal with conflict can also earn the business analyst more brownie points towards achieving a top of mind status. When conflict is not resolved within a project, it can add to delays and increased stress levels. Ambiguity can also create tension and conflict in a project. It is an expectation that while the business requirements from the business analyst should be devoid of ambiguity (especially in the waterfall driven environment), the business analyst should be able to handle ambiguity and make sense of it.

Proper stakeholder management also requires a careful study of his participants and engaging with them appropriately. It is not a one-size fit all approach. Knowledge of which stakeholders may throw a spanner in the works during that big walk-through session is necessary. Getting their buy-in before the meeting is just as important.

Some stakeholders require a one-on-one consultation before the big meeting; others are happy to know about your requirements during that big meeting. Some are satisfied with a one-pager or an email highlighting what you expect from them; others require the full story before the meeting. Some prefer a pictorial view of your requirements, while others would like a fine print.

Dealing with expectations efficiently will find the walk-through sessions a walk in the park!

Managing stakeholders go hand-in-glove with relationship building. The business analyst must realize that specification documents (whether as business requirements, functional requirements and even user stories) are not, and cannot be written in isolation. A business analyst who does this runs a risk of creating a ‘disconnect’ between himself, his business and the development team.

Furthermore, adaptability and flexibility together with knowing which skill to use and when are also essential characteristics. With good relationships, the business analyst can quickly put pressure on the delivery team, without alienating them, or begging them without feeling humiliated, and even convince them without offending them.

A business analyst cannot be top of mind without showing innovative ways of solving business problems. To do this effectively he or she needs to demonstrate an understanding of strategic objectives, i.e. why is his business going in a particular direction? Often, it requires a ‘big picture’ view which takes the business analyst from a departmental to an enterprise level. Presenting this big picture view builds confidence to identify the alignment between an individual project and what the organisation is trying to achieve.

With this comes the confidence to challenge the business if there is a misalignment regarding the organisational strategic objectives and the project. Arguing a case against a project that does not contribute value will put the business analyst in good stead with the business owner – especially after it has been proved correct by the lack of return on investment.

Lastly, nothing can replace passion, enthusiasm and dedication. These attributes cannot be measured, however, when they are not there – they are conspicuous by their absence! Business owners will notice a lack of passion for their work and a reluctance to do what is necessary. It is also self-evident when a business analyst only does the bare minimum. The business owner needs someone who can energize the team and ultimately go the extra mile!

Quick Intro to Decision Model and Notation - DMN

Arash — Wed, 10 Aug 2016 23:03:00 GMT

Decision Model and Notation in short DMN is a novel way to model business decisions. DMN allows capturing and modeling business decisions in a way that is easy to understand with business people and subject matter experts. It is a combination of:

Decision requirement diagram – DRD
Decision table
Boxed expressions
Friendly Enough Expression Language – FEEL

Decision Requirement Diagram (DRD)

This is a graphical model that allows modeling dependencies between input data, decision, business knowledge and knowledge source.

In DRD, the arrows show the dependencies between different nodes in the model. To put it in a simple way, you can read it as if the output result of some nodes will be passed as the input of the other nodes.

In the table bellow, all the elements on a DRD model are illustrated:

ELEMENT	NOTATION	DESCRIPTION
Decision		The act of determining an output from a number of inputs, using decision logic which may reference one or more business knowledge models.
BusinessKnowledge Model		A function encapsulating business knowledge, in the form of business rules, decision table or analytic model. Some of the tool may not support this element. In such case the decision logic is directly linked to the Decision rather than the business knowledge model.
KnowledgeSource		The authority for a business knowledge model or decision.
Input Data		Information used as an input by one or more decisions. It also denotes the parameters of a Business Knowledge Model.
Information Requirement		Information – input data or decision output – required for a decision.
Knowledge Requirement		The invocation of a business knowledge model.
Authority Requirement		Showing the knowledge source of an element or the dependency of a knowledge source on input data.

Decision Table

In decision model and notation, the Decision Table is a tabular form that models rules based on conditions and actions which they are also called inputs and outputs. Decision Table is the default type of modeling business rules in DMN. But if your tools support other ways to model business rules then you can freely use them along side with decision table.

Boxed Expressions

In Decision model and notation (DMN) are a simple two column table and effective way to model business formulas, calculations, values and expressions. And then you can share them across multiple decisions and logic.

Boxed expressions simply allows modeling: constant, values, invocation, formulas… Boxed expressions allows putting together building blocks of logic (i.e. decision table, natural language, flow…) and reuse them over and over again.

Friendly Enough Expression Language

In decision model and notation, FEEL is an expression language for business people. FEEL define a syntax for expressing conditions, actions and formula. Consider FEEL like excel formulas that they allow you formulate your thinking about a domain in a context. FEEL is designed to allow ease of use by business people and subject matter experts.

Advantages

There are benefits of using decision model and notation over the traditional business rules approach. In the business rules approach, very soon you start thinking about the business rules which they are more about the logic implementation. But decision approach provides a more high-level abstracted layer that allows you to see the big picture first rather than diving deep into implementation and losing the context and overview of the solution.

This change of approach:

Allows scaling business rules in more manageable, reusable visual approach across applications and processes.
Allows better communication between business, domain experts and IT by enabling a productive involvement of business people and subject matter experts.
Allows clearly define decision boundaries and expose the decision as a service with a click!

If your tool supports simulation and execution, error checking at design time and runtime with debugging capability then you will not miss anything from business rules approach, but also will have a better way to reuse and scale your business rules in a systematic way.

Submitted by: FlexRule

Glasses for Priority

Praveen Udupa — Thu, 19 May 2016 04:16:00 GMT

In my previous blog post titled "All requirements are important!",

I reasoned that stakeholders only appear to be uncooperative in the prioritization process. In reality, they are unable to prioritize requirements because they cannot see one requirement more or less important than the other.
I urged you to ponder whether it could be due to BA's drawback that s/he is unable to get the stakeholders to really see priority among requirements.

In this post, let us consider a few 'glasses', which will enable the stakeholders to see the relative importance among requirements. Here you go:

Glass #1: Business Value

Business Value is viewed in terms of faster, better and cheaper. Wearing the Business Value glasses, the stakeholders determine the degree to which one requirement contributes to the business to become faster and/or better and/or cheaper relative to the other requirements. Higher the business value offered by a requirement, higher its priority. Typically, business stakeholders weigh in on determining the Business Value of requirements.

Glass #2: Business Risk

Business Risk is viewed in terms of what can go wrong in the business. This must not be confused with what can go wrong to the system (that is implementation difficulty or technical risk). For e.g. introducing an interface between two systems will lead to a bunch of data entry operators losing their jobs. This is a risk although its impact depends on the risk appetite of the organization.

Wearing the Business Risk glasses, the stakeholders determine the degree of risk that the business would face because of a requirement relative to the other requirements. In other words, if that requirement was dropped, then the risk to the business is reduced.

Applying the general principle of fail early, fail quick when the cost of failure is low, higher the business risk posed by a requirement, higher its priority. However, this depends on the organization's risk appetite. Some organizations may choose to do the opposite. Typically, business stakeholders weigh in on determining the Business Risk posed by requirements.

Glass #3: Technical Risk

Technical Risk is viewed in terms of what can technologically go wrong during the implementation of the solution. Wearing the Technical Risk glasses, stakeholders determine the degree of technological risk posed by a requirement relative to other requirements.

Again, based on the general principle of fail early, fail quick, higher the technical risk posed by a requirement, higher its priority regardless of the risk appetite of the organization. Typically, implementation stakeholders like architects, designers and developers weigh in on determining the Technical Risk posed by requirements

Glass #4: Implementation Difficulty

Implementation difficulty is used when demonstrating quick success is important. In such situations, implementation stakeholders determine those requirements that are easiest to implement relative to other requirements. Lower the implementation difficulty of a requirement, higher its priority

Glass #5: Minimum Viable Product (MVP)

MVP is used to determine those requirements without which the product would simply be incomplete. You wouldn't purchase a car without breaks or mirrors for instance, would you? But you might consider buying the car without, for instance, automatic windows.

Thus MVP Requirements must have higher priority over other requirements. In this context, requirements that cater to a regulation must be a part of MVP.

Glass #6: Dependent Requirements

A requirement that by itself may not be treated as high priority, but if other high priority requirements are dependent on this requirement, then it is also provided high priority.

The above are some of the key glasses that can help stakeholders get over their "all requirements are important" syndrome and truly participate in the prioritization exercise. By the way, I am sure you realize that I only use the term "glasses" to extend the analogy from my previous blog. The proper term for glasses is "Prioritization Criterion or Parameter"

Are these the only glasses/parameters that you must use? No, absolutely not. In fact, some of the above parameters may not even apply in your project situation. You may find it necessary to use entirely different set of parameters. As a BA, you must first collaborate with the stakeholders must arrive at a set of prioritization parameters that are relevant to your specific project situation.

In my next blog, I will write a detailed note on the best practice process for requirements prioritization. Till then, I would love to read and respond to your comments...keep them coming!

All requirements are important!

Praveen Udupa — Wed, 18 May 2016 02:57:00 GMT

I was running a meeting with a few stakeholders. I was imploring them to indicate the relative importance of requirements, but was hitting a brick wall; they kept insisting, "They all look the same to me. All requirements are important. They all are must-haves."

I tried to reason with them multiple times over. There are just too many requirements, and cannot possibly implement all of them in the available time and/or budget. But they kept insisting that all requirements were indeed important.

I thought to myself, “Why are these people being so difficult? Why are they deliberately feigning ignorance?” I literally felt like tearing my hair out!

Have you been in this situation? I bet you have. Why is prioritization such a hard exercise? There must be a better way, right?

Let's rewind a little bit and review how we usually begin a Requirements Prioritization meeting: "Thanks for accepting this meeting. The purpose of this meeting is to prioritize the requirements. We are going to use the MoSCoW technique. Let us walk through each of the requirements and collectively decide whether this is a M, S, C or W."

Sounds familiar? If not exactly as stated above, it could be some flavor of the above. Instead of M, S, C or W, it could be some other rating mechanism. But, for the most part, the spirit is essentially the same.

My hypothesis is that, with the above expectations, stakeholders truly are not able to differentiate relative importance among requirements. They aren’t being difficult at all; they honestly cannot prioritize. Let me give you an analogy:

Imagine being in a corporate conference room. What can you find in there? Whiteboard, video con equipment, large table, uniform looking black chairs around the table, etc.

Suppose I ask you to arrange the chairs around the table in the decreasing order of blackness, what would you say to me? I imagine you would say, “They all look the same to me.” Exactly the way requirements appear to the stakeholders – all the same.

Suppose I give you a pair of glasses. Not any ordinary pair of glasses, but one that has spectrograph capability, and a display on the top right corner. When you wear this glass, and look at any object, a graph of various colors on the object along with their intensity represented numerically is displayed. Now would you be able to do arrange the chairs in their decreasing order of blackness? Sure you would!

Few questions to ponder over:

You weren’t initially able to arrange the chairs in their decreasing degree of blackness. Is that your fault? Does it indicate your weakness? Or does it point towards my weakness of not knowing how to enable you to do that activity?
Is it the stakeholders’ fault that they aren’t able to prioritize the requirements? Or is it my drawback as a BA that I wasn’t able to get them to “see” the relative importance among requirements?

Think it over. I would love to hear your comments. Let’s talk and engage in a productive discussion.

Meanwhile, in my next blog, I will write about the various glasses that you can provide to your stakeholders to get them to truly see the relative importance among requirements.

How A Dentist Appointment Made Me A Better BA

rlogan1301 — Tue, 17 May 2016 16:36:00 GMT

My youngest daughter was scheduled for her first dentist appointment. She couldn’t contain her excitement. She had her stuffed dog, dentist-visiting attire and bright, sparkling smile ready for the event. She was ready to go. Little did I realize that not only would my daughter come away with a clean-bill of dental health, but that I would come away a better business analyst as a result.

1. No pre-conceived notion – My daughter was excited with no apprehensions and no self-fulfilling prophecies to sway her. She had no idea what it was going to be like nor did she hold any opinions on the matter. She just knew that her older brother and sister went regularly and now it was her turn as a ‘big girl’ to go to the dentist! Kids are not born with pre-conceived views of the world. Most of what they experience is a surprise (pleasant or unpleasant) and an adventure. As adults, we have lived through many different experiences and as such, some of us dread going to the dentist. As a business analyst, we deal with pre-conceived notions on projects all of the time. End users, sponsors, subject matters experts all have some sort of view or opinion on the purpose (goal) of the project. Some views are positive (end users are really needing this enhancement) where other users are skeptical or out-right negative/cynical about the purpose. As a business analyst having a view or opinion of the project is ok, but I find one is far better served to suspend all judgement…the success of the project increases when the business analyst leaves his\her views at the door.

2. Curiosity - One of the results of my daughter’s experience was a ton of questions directed at me. “Why do you have to sit in a long chair?”, “Why does the doctor wear a mask?”, “Why do I need my teeth cleaned?”, “why?”, “why?”. Some of her questions may have been her wondering why I would do such a thing as to send her to the dentist, but I think most of them were simply driven by her basic and innate curiosity. In my opinion, curiosity is the foundation of a business analyst. This curiosity is the driver towards discovering root cause within a project and ultimately providing that “what is the problem we are trying to solve”…the real ‘a-ha’ moment. I have been on projects where, as a result of the “whys”, it was discovered that a technical solution wasn’t even needed and that a change in the business process, communication method or organizational structure would better solve the problem.

3. A constructive Lack of Inhibitions can go a long way…not being afraid to ask questions and not being reticent about not knowing the answers – after answering the litany of “why” questions thrown at me I came to realize that she was very courageous to even ask these questions. She wasn’t afraid that her questions may change my perception of her and she wasn’t afraid to challenge her father or the situation. Having the courage to ask “dumb” questions (even after being told there are no dumb questions) drives the conversation forward. It also encourages others to ask “dumb” questions because then, the underlying foundation for “if he can ask that then I can ask this” leads to better discovery and understanding.

4. Celebrate a Milestone - after her appointment what is a father to do? You guessed it...take her to get ice cream. Am I going to win father of the year? Probably not, but I wanted her to celebrate her first dentist appointment and her conquering something that was unknown and, possibly, scary with a positive “end note”. Participating in a requirement(s) sessions can be an unknown adventure that is both challenging and rewarding. Recognizing the successful completion of requirements for a project is a big deal and, as a business analyst, you should bring to light the major accomplishment (milestone) that it is. Do you need balloons and catered hors d’oeuvres? No, but explaining how the completion of this milestone will foundationally impact the rest of the project goes a long way.

I didn’t expect an innocent visit to the dentist office with my youngest daughter could correlate so closely with my daily challenges as a business analyst and provide me such insight into my profession, yet I remain grateful for the education and perspective I gained. I wonder what I shall gain in the years to come from similar experiences? I’m hoping I find such introspection and edification when the time comes for her to venture into orthodontia for braces.

Randall Logan is the President of PushPull, LLC (www.pushpulltech.com) a management consulting firm in Indianapolis. Randy has over 18yrs experience as a business analyst, project management, process analyst and consulting within the retail, manufacturing, finance, high-tech industries and can be reached at randall@pushpulltech.com

Stakeholder Requirement: Clarified

Praveen Udupa — Fri, 06 May 2016 10:54:00 GMT

This is in continuation of my earlier post on Business Requirement. If you have not read that post, I recommend you take a few minutes to study that first before continuing with this post.

In this post, let's discuss Stakeholder Requirement. Some people refer to this as User Requirement, but BABOK's nomenclature is Stakeholder Requirement. Understandably so, because a User (i.e. End User of the solution) is just one type of a Stakeholder. Other Stakeholders, not necessarily Users of the solution, may also have needs that they need satisfied by the solution.

Stakeholder Requirement describes how a given stakeholder would like to interact with the solution, in the context of a business requirement.

Let's observe a few points from the above definition of a Stakeholder Requirement:

1. We already know that Business Requirements must not include the solution. We have discussed this in my previous post. But while defining Stakeholder Requirements, the solution approach must be selected. How else would the stakeholders describe how they would like to interact with the solution?

2. If the solution approach changes, the Stakeholder Requirements also change (but the Business Requirements do not change)

3. In the hierarchy of Requirements, Business Requirements are at the top, immediately followed by Stakeholder Requirements. Every Business Requirement gets decomposed into its constituent Stakeholder Requirements. Stated the other way, one or more Stakeholder Requirements trace into one Business Requirement.

4. Stakeholder Requirements are not at a level of detail for the implementation team to design and develop the solution.

Let’s take an example to understand this better. In my previous post, we had discussed the example of an Insurance Company whose Business Requirement was Ability To Collect Premium Remotely. In order to meet this Business Requirement, there are several solutions possible:

First obvious solution: enable internet and mobile payment
Enable direct debit from the customer’s bank account
Partner with one or more banks and enable the banks to collect the premium
Authorize the agent to collect premium on behalf of the insurance company. The agent may then provide door collection service
Establish several satellite premium collection centers

Suppose we select the internet solution, i.e. the insurance company builds a website where customers make premium payments. The following would be some of the Stakeholder Requirements:

Customer: Ability for a Customer to view a list of all policies where premium is due

Customer: Ability for a Customer to make a payment for policy where premium is due

Admin: Ability for the Admin to update the list of policies where premium is due for all customers

Stakeholder Requirements form the basis for defining Solution Requirements. One might ask why bother defining Stakeholder Requirements at all, if it is not useful for the implementation team to design the solution. The reason is simple: A top down structured approach will ensure that the requirements coverage is close to 100%, and the probability of missing out on requirements is very low. Besides this, this approach helps minimize scope creep. I will write more about this in subsequent blogs.

"It should be black in color"

Praveen Udupa — Fri, 06 May 2016 10:44:00 GMT

Yes, yes...you are right. This is an elephant.

Well, no. This post is not about the elephant. The elephant is used only for symbolism.

And you are right...there are a lot of other similar posts out there. This is my take on this topic. It is different from others.

So, what does the elephant stand for? Think of a client who is getting killed by that one persistent business challenge. For this client, the business challenge seems "mammoth". And so does the solution to this business challenge - it is mammoth.

I am a Business Analyst working for a company that produces a product - doesn't matter what the product is for the purpose of this blog post. It could be a robot, a software application, a piece of furniture - well, absolutely anything.

It so happens that the client has chosen to purchase my company's product, because their due diligence has indicated that our product is a good solution to their "mammoth" problem.

As a BA, I am working with the client to understand what they "want" from the product. My conversation with the client flows as below:

Client: We have done our due diligence, and I know that your product is black in color. Right? We want one of the features of the solution as "black in color"

Me: Reflecting for a second. Sure, Sure... not a problem. It can be done.

Client: Good. Also, it needs to have rough skin. It must have four legs.

Me: Again, reflecting for a second. Not a problem at all. What else do you want?

Client: It needs to be able to carry cargo and passengers

Me: Sounds good! Not an issue.

Client: We cannot spend a lot on its maintenance. It must be herbivorous.

Me: Reflecting for a second again. Oh yes...true. Not a problem. Will be done.

Client: Oh, I almost forgot. It must have long trunk

Me: Stumped. Oh! You want a trunk? Can you manage without the trunk?

Client: Appears flustered by that question. No, No, No...absolutely not. Trunk is extremely important. Very. It must have a trunk

Me: Trying to salvage the situation. Alright! I will have it done. Anything else Sir?

Client: No, that will be all.

Me: Thanks much Sir. Could you sign off please? Right here on the dotted line.

I then return to my office with the signed off specs. I transition the requirements to the PM. The PM is not too worried. He thinks that the trunk is the only missing piece. He appears confident to deliver the customized solution in about 10 weeks.

I get a call in 6 weeks. The PM is super excited to show me the solution.

When the PM demo's the solution to me, I am super thrilled myself. I am ecstatic. I tell the PM that I will put in a glowing recommendation for her, and that I will personally deliver the product to the client.

So, here I am on my way to the client.

(Image copyright belongs to the owner)

Once at the client location, I demo the product with much excitement. To my dismay, the client does not share the same excitement. In fact, the client has a shocked expression on his face.

Client: What is this? This is not what I wanted.

Me: Confused. Referring to the requirement secs. What do you mean? This is exactly per the specs.

Client: Now getting agitated. I don't care what the specs say. This is not what I wanted.

Me: Trying to placate the client. Sir, I truly don't understand. You asked for four legs. There are four legs. You wanted herbivorous. I personally tested it, this is herbivorous. You wanted it carry cargo and passengers. Again, I personally rode on this thing. It is quite robust. You wanted it black. As you can see, it is black. You wanted one trunk. There is the trunk.

Client: Now getting progressively more agitated.

Me: Desperately trying not to die. Sir, my company takes pride in customer satisfaction. I for one believe in nothing less than customer delight. I have made sure to offer you something as added value that you did not even ask for. Sir, my product gives you milk. You have one more revenue stream Sir!

Client: Bordering furious. Get out of my office!

What is it that I did, or did not do, that got me into such a fiasco? Let's review:

You see, I did not do my job properly. Scroll up and review what my focus was while the client gave me his requirements. Did you catch it? Yes, that's it...that's what I am talking about. I was ONLY focused on reflecting whether my product already offered what the client was asking for. That doesn't seem like a right approach, does it?
Furthermore, I did not ever focus on WHY the client wanted whatever he was asking for. As a Business Analyst, my job is to first understand the WHY, and only then the WHAT. When the client asked for the trunk, I instantly realized that my product didn't offer the trunk out of the box. Instead of understanding why the trunk was required, what business purpose does the trunk serve, how it integrates with the rest of the solution, I was only focused on getting the client to relax the trunk requirement.
"Why" seems to be such a natural question to ask, isn't it? Why do you need the trunk? Why is it such a mandatory requirement? Even so, I did not venture to ask that simple question. How come? Here is the tricky part...if I do ask why, and then realize that my company's product does not meet the client's needs, I would have put myself in a precarious position. I can neither tell the client that my product will not help them (and risk losing the sale), nor can I tell that to my company. Instead, I do what I did...take the easy way out.

As a BA, one should never forget that the most important question to ask is WHY. Understand the business first before getting to the business requirements.

Business Requirement: Clarified

Praveen Udupa — Fri, 06 May 2016 09:38:00 GMT

"Business Requirement" is a maligned phrase. Different people have different interpretations for what it means. The worst interpretation that I have come across is, “hey, if the requirement comes from a business stakeholder, then it is a business requirement”. Requirement from business is NOT business requirement. For God's sake, every requirement comes from a stakeholder, otherwise it is not a requirement.

In this blog, I wish to clarify what exactly is a business requirement. I base this entirely on the best practice definitions documented in the BABOK v2 (and v3…truth rarely changes!)

Let’s take a short case:

Assume there is an insurance company that is dealing with a sticky business problem: they have a significant proportion of the policies lapsing by the first anniversary. In other words, the customers who buy an insurance policy today do not renew it the following year and, instead, let the policy lapse. Upon performing root cause analysis, the insurance company determines that the customers do not care to renew their policy because they don’t like to travel all the way to the branch office to pay the premium in order to renew their policy. In fact, they find commuting to the branch office so troublesome that they find it acceptable to let their policy lapse.

Now, what does this insurance company need to deal with the policy lapsing problem?

The insurance company requires an Ability To Collect Premium Remotely. This is a business requirement.

According to the BABOK, a business requirement is simply a statement of goal, objective or outcome of why a change is initiated. (Please see my P.S. at the end of this article)

Let’s take a closer look at the above business requirement:

Business Requirement exists in the Problem Domain. It captures the need of the business in order to eliminate a problem (actually the symptom). If the insurance company develops the ability to collect premium remotely, then, according to the root cause analysis, more customers will be willing to renew their policies, and consequently the lapse rate will decline.
Business Requirement MUST NOT capture how it will be met, i.e. the statement of business requirement must not include the solution. This is important. Very important. Well, why is this so? There are a couple of reasons:
1. First: Business requirements are developed during Enterprise Analysis (BABOK v2) or Strategy Analysis (v3). To be more specific, they are developed after assessing current state of the organization. At this point in time, no one even know what the solution is because it is not yet identified. Hence the question of including the solution in the statement of business requirement does not even arise.
2. Second: there always are multiple potential solutions that can be employed to meet a business requirement. If the statement of business requirement includes a solution, one would tie the organization to the said solution without considering any of the other solutions. In the above insurance company example, there are several solutions possible:
  - First obvious solution: enable internet and mobile payment
  - Enable direct debit from the customer’s bank account
  - Partner with one or more banks and enable the banks to collect the premium
  - Authorize the agent to collect premium on behalf of the insurance company. The agent may then provide door collection service
  - Establish several satellite premium collection centres

As you can see, any one or more of the above solutions will provide the remote premium collection ability to the insurance company. Thus, it is not prudent to include the solution in the statement of business requirement.

Most people whose role/designation is Business Analyst operate in the IT space. They define the requirements for an IT solution. More often than not, these BAs do not get to define the business requirements because they mostly never participate in Strategy Analysis projects. However, every BA participating in defining the User and Solution requirements MUST begin by understanding the Business Requirements.

More on this in my subsequent blogs...but for now, I will look forward to your comments!

P.S:

BABOK is probably confusing for a first time reader (even if this first time reader is a seasoned BA). The BABOK makes a confusing statement - it says business requirements are high level statements of goals. This seems incorrect because a goal and requirement are clearly two different things. Here is how I reconcile various terms:

First comes Business Strategy
Business Goals are defined from Business Strategy
Business Objectives are SMARTly decomposed from Business Goals
Business Requirements are high level statements of goals (not Business Goals) in order to eliminate a Problem that is preventing the org from meeting its Objectives, without including any indication of the Solution in its statement
Stakeholder Requirements (or User Requirements) are needs of Stakeholders from the selected Solution, in the context of a Business Requirement
Solution Requirements define the behavior of and constraints imposed on the Solution in order to deliver the Stakeholder Requirements

Business Analyst - The ONE – Part 4

RANGA — Mon, 25 Apr 2016 12:59:00 GMT

We saw about the problems and the ways of defining a solution to those problems in the last article. Also, I had mentioned that when a problem arises, there is a need for the business to resolve that problem. So, what would be business needs? It again depends on the problems which they face. By definition, Needs are desires of the project customer that focuses on a business problem; its fulfillment is strategic to organization goals. In IT world, it is to identify and define why a change to an organizational system or capabilities is required.

Determining specific business needs is the main objective which as a business analyst you might need to clarify and understand it completely in order to be most effective, as the solution is driven by those needs and your project will also be evaluated based on those.

Most of the business needs arise due to the common issues such as loss of revenue, customer complaints or a direction towards which the entire organization need to move, like regulatory bodies defining a common rule which need to be followed by all the organizations. In our previous example on the problem faced by the hotel business on customer smoking, the main business need was to eradicate this particular problem which was resulting in bad customer experience and due to which there was a revenue loss. So, without someone acting as an analyst, the business wouldn’t have a compass or a map to guide them in resolving such issues.

As an analyst, here you are in the role of defining the needs from the business point of view (remember the initial writing, where I mentioned the different type of business analysts, this role is more from the person who is working from business side to provide the details to the technology or provide solutions by themselves), you are expected to define the business needs considering the following points

1. How then different stake holders like end users, front-line workers, management, vendors or any other stake holders / different business units define the perceived problem?

2. The areas which are affected by the problem, like client retention, gross/net revenue or development budgets etc.

3. Feasibility, drawbacks and benefits of suggested solutions to eradicate the mentioned problem, like in terms of manpower, revenue, capacity.

When you say you need to define a business need, you can represent that need in terms of multiple ways. When there is a technological improvement required based on your business need and when you are trying to define the business need for technology to understand, don’t define in such a way that what you want system to do for your need, define what your expectation from the need for your business improvement. As when it is defined in terms of what business need is that time, the change in the business based on that need is also identified. So, think and specify your needs in terms of new, value-delivering processes and opportunities like how you want to work in the future, the process steps, information needs and process logic. Then you'll have systems that align exactly with your needs.

The business need is not typically a stand-alone deliverable or document. Instead, the business need is a very high-level business requirement that should be included in the business requirements document or business case for your proposed project.

In traditional method of defining a need, an analyst will define the need in terms of his requirements, corresponding document known as Business Requirements Document and all the details of the changes that are expected shall be incorporated in to one single document. In modern trend, everyone being agile in their process, the needs are split in to individual stories and each story explaining a specific requirement for that need. Since the story is defined by the end user, it is again termed as a User story and a model user story will look like below

As a hotel manager, I need to have smoking zones in my hotel so that I can have a better customer experience and increase in revenue because of that.

To define the business need and understand the desired outcome, try brainstorming with end users and personnel, analyzing the current ways the company does business to identify weaknesses, interviewing subject matter experts, and holding focus groups for stakeholders and users. Analyze every aspect of the business, even those you aren’t confident are part of the issue.

So, what’s next!!! Yes, now we have “opportunities” to explore further :)

Business Analyst - The ONE – Part 3

RANGA — Mon, 18 Apr 2016 12:57:00 GMT

Till now whatever we have seen was more from a bank point of view on few of the roles and responsibilities of a business analyst. Let us see on day-today what a business analyst might be doing!!!

Before understanding what business analyst do, let us understand why any business need an analyst. By definition, an analyst is the individual who analyze on any given topic, he is the one who examines and reviews the data or information or any specific area, like financial analyst look in to the economic and financial information associated with the stocks and securities so as to provide suggestions for the organization on investing on those stocks/securities. So, what exactly these individuals are doing for the business, they are helping the organizations to identify the problems, opportunities and needs and provide solutions for the problems, help in grabbing the opportunities and implement the changes that are required to satisfy the needs. This is the one of the many reasons why any business needs an analyst. Now that we know why business needs an analyst, you would also have figured out what could be the roles & responsibilities of them, yes you are thinking right, it changes according to the business need.

Let us concentrate on these problems, needs and opportunities and accordingly try to see what may be required for an analyst to do in such situations. All these three terminologies are co-related. In every problem faced by business there is a need for them to solve that and it creates an opportunity for an analyst to pitch in to resolve the problem. All business, whether small or big, faces issues/problems. Depending on the type of the problem, the solution needs to be arrived.

Let us consider a simple example of a problem in a hotel business, assume that the problem is smoking and because of customers smoking in common rooms, affects other customers, who don’t appreciate the smoke causes low customer satisfaction. To overcome this simple problem, an analyst works on identifying the problem on customer dissatisfaction so as to provide a solution. First he need to figure out the problem, this can be done by various methods, however let us assume he already identified this problem of smoking based on customer response to the satisfaction survey he conducted. Now he need to write down the problem statement as a first step, a best problem statement post identifying the real problem would be something like below

The problem of customers smoking in our rooms affects other customers, who don’t appreciate the smoke and smell, and our housekeeping staff, who spend significantly more time cleaning smoking rooms versus nonsmoking ones, the impact of which is low customer satisfaction, reduced occupancy rates, and increased cleaning costs. A successful solution would be to eliminate smoking and smoking effects from our hotel rooms and readdress those impacts.

To arrive at the solution, he need to do the following

1. Identify the root cause of the problem, which in our example is customers smoking.

2. Identify as many as solutions possible, i.e. identify multiple possible solutions which can resolve the problem

3. Prioritize potential solutions, meaning identify which you foresee as an acceptable solution for all.

4. Make a decision to select the best one out of the identified solutions. This can be a collaborative effort along with the stakeholders of the problem and as well as the business owner.

Post identification of the solution, it doesn’t stop there, assign responsibility and set a measure / target to ensure that problem is not repeated again.

Whatever I have told, even though generic, is applicable for any problem in any of the sectors where technology is involved. So, as a business analyst, you always need to identify the root cause of any problem and try to fix that so that it is not repeated again.

So, can we identify the best possible solution to the above problem? :)

What we are left with to ponder around, yes, you are right, needs and opportunities … let’s wait for few more days :) ...

Business Analyst - The ONE – Part 2

RANGA — Tue, 01 Mar 2016 13:55:00 GMT

Now, I am a BA. My role of doing the routine operational work is no more there. Now I am in to the mode of asking questions. So, what are the questions I should be asking? How am I supposed to interpret the answers? How do I build my knowledge on the process based on these answers? How can I contribute to the improvement of the process? These are few questions, which came to my mind when I started this role.

Note that I am writing this article more from technology and banking point of view. However, I will try to generalize the same in future articles.

I had joined a technology organization after working for many years in banks, however was still supporting a bank as a business analyst on behalf of this technology organization. As I mentioned earlier, my understanding on the role of a BA who is working for a Bank is to ask questions so as to analyze the process happening around the bank and provide solutions for the process improvements, either technological improvements or operational process improvements. With this understanding, I started working for the technology organization; however things were slightly different out there. When you are part of a technology team from the bank, your main goal becomes providing solutions towards enhancing the systems that are being supported by the technology teams or support for enhancement of the systems used or developed for the Bank, either it is in house (built by the bank’s technology team) or it is an external system (supported by another technology organization). So, the questions you ask shouldn’t be restricted only to improve the process followed in banks, but also should be from the supported systems point of view, i.e., those questions should also be more from technology point of view whether such process enhancements are feasible from the existing system point of view or not. This would be quite challenging, as you are not only acting the roles of a business analyst in asking questions to analyze the processes alone, but also understand the systems used so that you can translate the business requirements in to functional specifications for the understanding of the developers to enhance the system. Confusing? Or Interesting!!!

To avoid confusion, if any :), let us see understand the difference in the activities performed by the business analysts in these banking and technology sectors. Let us say,the Bank uses two different systems Alpha & Beta for one of its processes, Alpha being an external application supported by a technology organization & Beta being an in-house application developed by the technology team of the bank. Also, assume Oliver is a business analyst who is working for the Bank, Mark is a business analyst working for the technology organization & Bob is a business analyst who is working for the technology team of the bank.

For Oliver, since working for the bank directly as a business analyst, his role is more to understand the business process and provide process improvement ideas, so he creates requirements that need to satisfy the business needs on behalf of the bank, the documentation created for this purpose termed as Business Requirements. Note that he will not be concentrating on whether for the process enhancements, which systems need to be enhanced. He will more be interested on how those business requirements can be put in place for business efficiency, so he will wish to see the end results by testing those requirements. So, the questions he will be asking business will be more from this point of view of whether the suggestions he is providing to enhancing the process, results in business benefits.

The roles of Mark & Bob would be the same from their respective applications support point of view; i.e. they need to analyze those business requirements given by Oliver and come up with solutions for enhancing their respective systems Beta & Alpha. So, what they will do is translate those business requirements in to the language in which developers can understand and enhance their respective systems according to the requirements, the document which is created for this purpose is generally termed as Functional requirements. For this, they need to understand the business requirements thoroughly, until they are very clear so that they can provide solutions on how the requirements can be fit in to their systems. How they understand the business requirements, is again by asking questions, but these questions would be more not only from business point of view, but also from technology point of view, like whether the business process enhancement suggested really helps business or not? How much efforts required for them to enhance the system? Will that enhancement really be worth to do?, the results of these questions, rather the answer to these questions will result in identifying the impact to their respective systems and the supporting stake holders, if any, which is being termed as “Impact analysis” or “Functional Impact Analysis”. They also need to support the development team in terms of testing the requirements before them handing over the product to Oliver for him to test the final output. This testing done by the testers, with the support from Mark & Bob, is termed as SIT (system integration testing, performed by technology with the help of technology BAs) and the testing done by Oliver along with the end users to ensure that the final output meets the business requirements which was given initially is termed as UAT (User acceptance Testing, as Oliver is the business representative, who is acting on behalf of the user). Also, note that the roles of Mark & Bob will slightly vary depending on the respective systems they support.

I think I have introduced more terms now to make it more confusing, relax, its simple. So, what you think? Are we done with all the roles and responsibilities of the BAs!!! No, please wait for the next article to come, as we have a long way to go :) …

Business Analyst - THE ONE - Part 1

RANGA — Thu, 11 Feb 2016 13:49:00 GMT

Business Analyst – First time when I heard this word while working for banking operations, I was really curious to know more about the role behind this word. One fine day, I was introduced to a person by my senior manager and was told that I need to explain him on the processes which we were doing in the banking operations. I initially thought this explanation is going to be a cake walk for me, as working monotonously for more than 6 years on the same products and operations team and teaching being a passion and almost all the new joiners have been trained by me, I was thinking that explaining the person wouldn’t be a big challenge. Conversation began with me explaining him on the entire operational flow of funds transfer and mutual funds. Later, he shoot me with his questions (there came the darker side) on the end to end flow or rather life cycle of a funds transfer or Mutual funds. That was the time, when I realized that I have limited myself to a certain level of learning, thinking that it is the whole process by itself and I have way more to learn than I could imagine. I was so fascinated by the way he was asking queries to me, as none of those, I could answer at that moment, but answered with a smile that I will let him know by the next week, hearing this, he left for that day. Out of curiosity, I asked my senior manager, who was that person who was literally interrogating me with his questions to which I was totally blind-stuck. He said he is a Business Analyst who has come for understanding the entire process that is being followed, so as to provide ideas on improvement of the processes. Trust me, that was the first time, I know that even Banks hire Business analysts.

Next week, I was well prepared to answer all his queries he asked me the previous week, I had went beyond my level to understand the complete flow touching base with front office, middle office and even within my operations team. I could answer all the queries he asked, as I myself had understood the entire flow of funds transfer and Mutual funds, not only from operations point of view, but the end to end life cycle. He was happier that he got all his requirements. This time I asked him directly “Sir, what should I do to become like you?” he smiled and said “You have already become one when you were able to answer all the queries I asked, as you have the answers, it is just that you need to convert your answers to questionnaires, so keep on asking “How”, “Why?”, “What” & “Where” like “How sooner you can complete this if you do like this”, “Why we need this process”, “What is the risk the Bank would face if this is done this way”, “Where is the data coming from””. That was the day, when I started transforming myself from a role of a Manager doing routine operational work to a Business Analyst who understands the end to end flow of everything across he was working, to put it in the Matrix words, I became the ONE who already know the answer to the question which I am going to ask.

Now that I have become a business analyst, thinking that only asking questions to the answers which I already know will make me a successful one in that field, proved later that my assumption was completely wrong and there is way more to be done on that role than what I was thinking.

So, let’s see what you are expected to be doing practically while working as a business analyst in a next article

Decision Model and Notation to model Business Policies

Arash — Mon, 01 Feb 2016 21:55:00 GMT

Decision model and notation (DMN) is a nice way to model policies and make sure your business rules are implemented properly. Opposite to traditional approach in business rules which was the focus on the rules them selves, in DMN we start from decisions.

Let’s work on a tangible example. In an employees benefits and entitlement system, you would have many rules, which some of them are related to calculate the employee Vacation Days. For example let’s say your company has the following policy:

Every employee receives at least 22 days. Additional days are provided to the following criteria:
1. Only employees younger than 18 or at least 60 years, or employees with at least 30 years of service will receive 5 extra days.
2. Employees with at least 30 days of service and also employees of age 60 or more, receive 3 extra days, on top of the possible additional days already given.
3. If an employee has at least 15 but less than 30 years of service, 2 extra days are give. These 2 days are also provided for employees of age 45 or more. These 2 extra days cannot be combined with the 5 extra days.

(* The policy example was provided by Prof. Jan Vanthienen)

Now let’s have a look at the bellow model:

Each of the blue rectangles are called “Decision” and each line with arrow shows the dependency of each decision to another or to an input data (employee in round rectangle with pink color).

Now we need to build couple of simple decision tables. And then associate each of them to appropriate decision node in the above decision requirement diagram.

Base days

Every employee receives at least 22 days.

Base days

Extra 3 Days rules

Employees with at least 30 days of service and also employees of age 60 or more, receive 3 extra days, on top of the possible additional days already given.

Extra 3 days vacation

Extra 5 days rules

Only employees younger than 18 or at least 60 years, or employees with at least 30 years of service will receive 5 extra days.

Extra 5 days vacation

Extra 2 Days rules

If an employee has at least 15 but less than 30 years of service, 2 extra days are give. These 2 days are also provided for employees of age 45 or more.
These 2 extra days cannot be combined with the 5 extra days. (This part is handled where we add up all the values in Total vacation days)

Extra 2 days eligibility

Total vacation days calculation

In the upper left side decision, we calculate the total days based on eligibility for base days and extra days:

Total vacation days based on other decision tables

We also set the last table aggregation method to Sum based on Rules Order. So the result will be sum of the last column (Vacation Days).

Decision model and Notation defines couple of standard aggregation functions.

Benefits of this Approach

If you model only the Decision Tables, for a slightly more complex policy you will loose the big picture and will have no clue about the whole policy not scenario that is covered. But by using the Decision Model and Notation (DMN), you start from top, and then drill down to each decision implementation (Decision tables) or other types of logic.

Project Management with Mind Maps

Surbhi Mahnot — Thu, 21 Jan 2016 06:35:00 GMT

Prepared by MindMeister tool

Have you ever planned a project or brainstormed an idea? It takes a lot of effort to manage the collected information in a way you can easily traverse through.

On occasions you find yourself occupied with a lot of questions and confusion in scenarios such as

You have a lot of details to get started with but no clear picture of how it all fits together

You are prepared with the plan but find it difficult to explain to team members or co-workers or even to your boss
You are facing difficulty in tracking and mapping all the comments and discussions with the requirements

This is where mind maps can emerge as your savior.

Mind mapping is an effective project management technique to help visualize project features, to plan effectively and to enhance creative problem solving abilities.

Consider it as an empty canvas to draw your ideas in a structured manner centered on one single concept.

A “good” mind map shows the complete structure of the project with all the relevant details and emphasis set properly on all important aspects. It helps you break a consolidated idea in smaller pieces that makes it much easier to plan and manage.

Mind maps are often used to generate, visualize, organize and showcase anything related to personal or business tasks such as financial plan, travel plan, scoping, management processes, sales processes, etc.

Basic guidelines of a mind map

Start with one topic
All the ideas must be connected to the center topic
The ideas can further delve into sub ideas in any level of hierarchy, resembling with a tree that has multiple branches
Use images, symbols and icons to emphasize
Use color to distinguish ideas
Have connections, associations, dependencies in your map wherever required

Good rule(s) of thumb

Do not use lengthy texts to describe an idea. Try to use phrases or short words. This makes map more focused and clear. All the details could go into notes
Use simple language that is easy to understand
Don’t add extra complexities such as excessive images, icons, colors, connections that makes the map difficult to follow for others

Mind maps could easily be drawn on a piece of paper or on a board. Also, there are many tools available to help in creating quality maps quickly like Bubbl.us, Mindmeister, iMindMap, Mindjet and MindGenuis. A complete list of tools is available here.

Practical applications and benefits

Brainstorming

Mind maps come very handy in brainstorming requirements and organizing ideas.

They are an efficient way to break large plan into small manageable chunks.

Helpful Tips

List all your ideas centered on the topic initially, with no established relations or connections. Any feature that could add any value to the central idea, put them on map
Dig deep with each feature individually and list all functionalities that could be covered
Set priorities by adding numbering
Add icons, colors and images to uniquely identify features

All this helps in keeping track of all the requirements and help in preparing a quality scope for the project.

2. Planning

Mind mapping promotes effective planning without getting overwhelmed with the project requirements and complexities.

Helpful Tips

Identify dependencies or associations or connections between all the features of the project
List probable assumptions and risk factors either for every feature or for the overall project
Plan development or execution of project in Milestones/Iterations by identifying the priorities, complexities and efforts. This will help attain a broader picture on overall aspects and set detailed focus
Summarize all the information, revisions, discussions as “Notes” in the mind map against each module to keep a better track of everything

3. Decision Making

Well laid plans always help in taking better decisions.

It is always better to take decisions from a well-developed plan that can be visualized. The same decisions could probably be achieved in traditional manner using excel or word document with detailed description as well, but visuals always tend to make more impact than just plain text!

Decision trees could be easily plotted with mind maps to map all the scenarios, risks, complexities and connections and then decide the best way to go ahead.

4. Problem Solving

Mind mapping is a way to promote creative thinking.

It can bring following benefits in improving problem solving abilities

Mind maps allow quick reviews. As all the details are laid visually, it becomes easy to follow
It can act as mnemonics to help you remember the short phrases and words

5. Communicating details to your stakeholders

Visuals always aid in providing better explanation and bringing clarity in thought process.

With mind maps, it becomes very easy to share the on-going thoughts with all the involved stakeholders

The discussions could be saved to act as an important reference material at later stages
They minimize the chances of lack of clarity or misunderstanding which could save a good deal of time and arguments at later stages

6. Team co-ordination and discussion

Mind maps save a plenty of time in explanation. The details are well laid which makes it easier for individuals to understand and relate with the project better. It can provide

Complete documentation tracked at the same place
Clear representation of hierarchies and associations/dependencies
Recorded details, notes, references throughout the project life-cycle

These were just a few of the many possible applications of mind maps. If you do any kind of research, get stuck with a problem, want to brainstorm on any topic, need to prepare a plan, try Mind Maps. You’ll love using them!

References

Check out these mind map galleries and resources to learn more about mind maps

Learning Fundamentals — mind mapping tricks and trips, particularly for paper
About mind map — basics about mind maps
Mind map strategies — blog about mind maps
Mind-Mapping.Org — one of the most extensive pool for mind map resources, blogs and details
Mappio — contains thousands of mind maps
99 mind mapping resources, tools and tips — get a quick glance of all the resources, tools and tips

The article was originally published on Medium.com by @surbhimahnot

Top 10 mistakes in Use Case Modelling

Trividh Patel, CBAP — Mon, 11 Jan 2016 03:10:00 GMT

Use case modelling is the most powerful requirements modelling technique to model solution requirements if applied correctly. I have come across many BA teams (including my own) that made lot of common mistakes in use case modelling. By avoiding the top 10 mistakes identified in this paper, BA teams can not only save lot of efforts in use case modelling but also significantly enhance the value delivered and improve the satisfaction of stakeholders.

1. Naming the actors using the job titles

Job titles and actor names are two different things and often cause confusion. This is because two different users, with different job titles and organizational responsibilities, may have to use the system as a same actor; for example, a supervisor can have access to and use the functionality used by his/her subordinate. Actor is a role that is with respect to the system as opposed to a job title which a role with respect to the organization. Job titles may typically determine user types. Remember, job titles of people may change but the roles they play would remain relatively stable.

2. Creating only the use case diagrams

Use case diagrams only provides summary of the relationship between the actors and the use cases. Can we tell what a system does basis only the use case diagram? No; a system cannot be built just based on the use case diagrams. We need detailed use case descriptions to design and build the system.

3. Not capturing enough details

Too much detail can obscure the flow of the use case and too less can make it really meaningless. “How detailed a use case should be?” In as much detail as possible and in as much detail that is required to make them unambiguous to describe what the system must do. Focus on what is important and continue to add details till all the stakeholders are satisfied.

4. Describing everything a system does in a use case

It is important to identify all the use cases and describe them so that everyone understands who uses the system and what goals they achieve by using it. This is particularly important when the user-system interaction is complex and detailing the system behaviour is essential to develop and test the system. However, if we blindly do this for all the use cases than we are just increasing the documentation and subsequent time required for reviews and sign-off, without delivering any additional value to the project and its stakeholders. So, for cases where the user-system interaction is simple, use cases are not required to be fully described. In such cases, a simple use case description supplemented with declarative requirements and other models may be sufficient to understand what needs to be done.

5. Performing functional decomposition

BA teams typically tend to group functional requirements, or break them in form of functions or menu-items and identify them as use cases. What they don’t understand is, high-level use cases cannot be decomposed into lower-level use cases and also use cases cannot call, communicate, get linked or sequenced with other use cases. This approach is most common of all mistakes made while identifying and describing use cases. Let us try to understand this with an example.

What use cases will you identify for a system say, a car? The adjoining diagram shows the use cases identified using this approach. Here, all the necessary functions (menu-items!) are available to a ‘Car Driver’ (actor) to drive a ‘Car’. With this approach, are we answering what the ‘Car Driver’ will do to drive (actual goal) the ‘Car’? None of the use case actually describes the way ‘Car Driver’ will interact with (or use) the ‘Car’ to drive it without linking or sequencing them. The system appears as a large set of disconnected functions. To identify the right use cases, always keep in mind the goal that the actor wants to achieve by using the system. Each use case must be complete to provide value to at least one of its actors.

6. Writing perfect use cases

There is no such thing as perfect use cases. Many BA teams waste their efforts in trying to create perfect use cases. The focus should be on making use cases as good as required for facilitating communication amongst stakeholders to achieve shared understanding of requirements and moving to system design, development and testing.

7. Detailing use cases with the CRUD behaviour

Although it is not technically wrong but detailing uses cases with CRUD (create, retrieve, update, delete) behaviour, for example maintaining information for administrative systems, is a waste as it is mere repetition of declarative form of requirements specifications. Use cases with the CRUD behaviour don’t add much value to ensure that the system is doing right, particularly when information can be added in any sequence without any dependency. Except for data validation rules and specific fields to be entered, the use cases with the CRUD behaviour become repetitive. These efforts can be used for detailing use cases with real flow of events.

8. Using the use case model to design the system

Many times, BA teams also document how a system should handle certain functionality internally as part of use case descriptions. By specifying such functionality we are imposing constraints on the development team to design the system in a specific way. Many would argue that “it is a BA’s job to think for all scenarios and provide a solution” but we forget that the real purpose of a use case is to describe what system does to fulfil the goals of the actor and by mentioning constraints inside a use case we are just making this behaviour difficult to understand. So, anything that must be handled in a certain way should only be described in the use cases and all other things should be left out for the developers to decide. Constraints can be captured in other specifications and traced back to the use cases so that they are not forgotten during the system design. Use case model must never be used to design the system. Use cases describe what the stakeholders want the system to do and not how the system implements the functionality.

9. Describing things outside scope of system

Use case model captures the interactions of actors and the system and describes what the system does to fulfil actor goals. Outside system boundary a stakeholder (identified as an actor) may interact with another stakeholder (who may be identified as another actor); to support the business process. If this interaction (business process) is not supported by the system, it should not be captured in the use case model. Use cases can be used to capture business processes as “business use cases” with actors outside the business boundary. Never mix systems use cases and business use cases.

10. Misusing the use case relationships

BA teams also spend lot of time structuring the use case model, with use case relationships such as include, extend and generalization, assuming that such structure is required in every use case model or required for the system’s architecture. BA teams typically useinclude relationship to break a use case into smaller use cases by performing functional decomposition of the system. The result is that none of the use cases by themselves provide any real value as it becomes very hard to see what a system does. Using use case relationships without understanding their real purpose just results into a confusing use case model.

About Author

Trividh Patel, CBAP® has well over a decade of experience in an IT services industry, in various functions such as Business Analysis, Business Technology Services, Presales, and Project Management, primarily in Banking, Financial Services, and Insurance domain.

Trividh has done his MBA from JBIMS, University of Mumbai, and Bachelor of Engineering from VJTI, University of Mumbai.

Trividh Patel, CBAP® provides specialized Business Analysis Trainings, such as

1. Fundamentals of Business Analysis
2. Mastering Use Case Modelling
3. CBAP® / CCBA® Certification Prep Course

Trividh Patel can be reached on -
LinkedIn: http://www.linkedin.com/in/trividhpatel

Research: Roles and background before becoming a Business Analyst

Trividh Patel, CBAP — Mon, 11 Jan 2016 02:28:00 GMT

I am pleased to share the analysis of a Qualitative Survey to understand the backgrounds of Business Analysts (BAs) and the roles they have held prior to becoming BAs. This survey was conducted as an informal poll on LinkedIn. The numbers of participants are over 250 and hence are statistically significant to infer.

Inferences

Developers/ Programmers are the highest to become BAs (most of them after becoming a Tester, QA Analyst, Systems Analyst, or Project Manager).
Business side Subject Matter Experts (SMEs, including end-users) are the 2^nd highest to become BAs (some of them after becoming Tester or Project Manager).
Project Managers and Systems Analysts are the 3^rd highest to become BAs.
MBA and Bachelors degree in Information Systems has helped to directly become a BA.
People with other roles/background that have become BAs include
- Testers and QA Analysts
- Application Support and Customer Support
- Sales, Marketing and Relationship Managers
- Data Analyst
- Technical Writers (including those working on proposals)
- Technical SMEs (Implementation/ Configuration Analysts)
- Project Coordinators

Conclusion

People from diverse backgrounds (technical, business, support etc) and roles have become BAs but there is no one particular path that can suit all, hence your own efforts and hard work will get you where you want.

Trividh Patel, CBAP® provides specialized Business Analysis Trainings, such as

1. Fundamentals of Business Analysis
2. Mastering Use Case Modelling
3. CBAP® / CCBA® Certification Prep Course

Trividh Patel can be reached on -
LinkedIn: http://www.linkedin.com/in/trividhpatel